> Zakladamy opensource, czyli algorytm jest znany (ale nie znamy kluczy).

Jakie są wszystkie konieczne warunki, aby w ogóle można było łamać
stały (nie losowy) ciąg zaburzający (zwany solą w oku):

1) Nie został zmieniony algorytm kodujący w tym opensource
2) Nie została wydłużona długość stałego ciągu zaburzającego, ma np. tylko 64bity
informacji
3) Wyciekły tablice zakodowanych haseł
4) Loginy były zapamiętane razem z hasłami i też wyciekły
5) Chociaż jeden użytkownik powie łamaczowi który jest jego login
6) Nie ma w systemie słabszych punktów - to jest bardzo ciekawy punkt. W systemie np.
nie ma
błędu programisty który umożliwi prostszy atak, nie ma nieuczciwego administratora
w kadrze, nie
ma dziury w jakimś innym serwerze. Pamiętajmy, że pomimo iż nie ma takich słabych
punktów, to
jakimś cudem był słaby punkt, który umożliwił akurat wyciek haseł i loginów.
Jednocześnie,
pomimo braku innych słabych punktów, nie wydłużono soli i nie wprowadzono jakiejś
zmiany do
algorytmu kodującego. Ja tutaj widzę lekką sprzeczność, ale powiedzmy że opisywana
przeze mnie
sytuacja jest możliwe.
7) No i oczywiście jest w programie to rozwiązanie, które nie wydaje mi się bardzo
lamerskie: czyli jest stały ciąg zaburzający.

Co trzeba zrobić aby odzyskać ten stały ciąg zaburzający? Można
łamać brutforcem, potrzebujemy:
1) 1mln jednostek przetwarzających,
2) szybką implementację
3) około 1-3 miesięcy czasu
4) kilka milionów usd na energię elektryczna

Nie wiem czy można go łamać tęczowymi tablicami, jeśli można, to ile potrzeba
zasobów? Przypomnę, mamy krótki, 64 bitowy, losowy-stały ciąg zaburzający.

Pozdrawiam

do góry

Dnia 12.11.2014 M.M. <m...@g...com> napisał/a:
> Co trzeba zrobić aby odzyskać ten stały ciąg zaburzający? Można
> łamać brutforcem, potrzebujemy:
> 1) 1mln jednostek przetwarzających,
> 2) szybką implementację
> 3) około 1-3 miesięcy czasu
> 4) kilka milionów usd na energię elektryczna
>
> Nie wiem czy można go łamać tęczowymi tablicami, jeśli można, to ile potrzeba
> zasobów? Przypomnę, mamy krótki, 64 bitowy, losowy-stały ciąg zaburzający.

Przy losowych "solach" mozesz userowi udostepnic program hashujacy (moze
byc nawet zrodlowka czy program napisany w jezyku skryptowym - nie musisz
ukrywac zarowno kodu jak i jakiejkolwiek stalej w nim zawartej) a plik z
zakodowanymi haslami mozesz upublicznic a i tak zlamanie hasel (nawet jesli
to sa proste slowa ze slownika) bedzie trudnym zadaniem. Przy stalej "soli"
(na twardo zapisanej w kodzie) musisz pilnowac znacznie wiecej elementow,
miedzy innymi musisz zadbac o nastepujace sytuacje:
- user nie moze miec dostepu do zakodowanych hasel innych userow (na
wypadek gdyby ktos inny uzyl takiego samego hasla)
- user nie moze miec dostepu do kodu zrodlowego programu (odpada
impelementacja w jezyku skryptowym), bo "sol" jest w nim w postaci jawnej,
a nawet jesli to jakos "zaczarujesz" i ukryjesz jakos w kodzie, to mozna po
prostu fragment kodu (tym z "czarami") uzyc bezposrednio do metody
slownikowej
- jesli implementacja jest na przyklad w C, to mimo wszystko user moze
uruchomic ten program pod debuggerem i sledzic jego wykonanie
(albo zresourcowac kod lub podejrzec "sol" w binarce)
- jesli masz osobny serwer autoryzujacy i padnie dysk w macierzy na ktorej
stoi cala autoryzacja hasel, to po prostu go wyciagasz i wyrzucasz do kosza
a wszystkim userom ustawiasz koniecznosc zmiany hasla przy nastepnym
zalogowaniu (nie przejmujesz sie tym, ze ktos wyjmie dysk ze smietnika i na
jego podstawie zlamie hasla w krotkim czasie)

Po prostu - losowa "sol" moim zdaniem ma bardzo wiele plusow w stosunku do
zakodowanej na twardo i moim zdaniem sol zakodowana na twardo wynika
glownie z lenistwa programisty :D Oczywiscie to tylko moje zdanie - nie
upieram sie, ze jest jedynym slusznym ;)

do góry

W dniu 2014-11-12 o 19:59, Piotr pisze:
> Przy losowych "solach" mozesz userowi udostepnic program hashujacy (moze
> byc nawet zrodlowka czy program napisany w jezyku skryptowym - nie musisz

Ale losowa sól musi być taka sama przy tworzeniu każdego hasha jak i
przy sprawdzaniu. Jeśli nie jest zaszyta w kodzie programu, powinna być
w pliku konfiguracyjnym i nie zmieniana?

do góry

> Przy losowych "solach" mozesz userowi udostepnic program hashujacy (moze
> byc nawet zrodlowka czy program napisany w jezyku skryptowym - nie musisz
> ukrywac zarowno kodu jak i jakiejkolwiek stalej w nim zawartej) a plik z
> zakodowanymi haslami mozesz upublicznic a i tak zlamanie hasel (nawet jesli
> to sa proste slowa ze slownika) bedzie trudnym zadaniem.
Ja chyba czegoś nie rozumiem. Moim zdaniem będzie łatwym zadaniem.
Pokaż mi gdzie popełniam błąd:
1) Bierzemy słownik.
2) Bierzemy hasło i jego sól
3) Każde słowo ze słownika solimy i hashujemy
4) Wyświeltamy te słowa, które dały taki sam hash, jak w udostępnionych
plikach.

> Przy stalej "soli" (na twardo zapisanej w kodzie) musisz pilnowac
> znacznie wiecej elementow,

> miedzy innymi musisz zadbac o nastepujace sytuacje:
> - user nie moze miec dostepu do zakodowanych hasel innych userow (na
> wypadek gdyby ktos inny uzyl takiego samego hasla)
Nie moze miec dostepu zarówno do hasel i loginow. Jesli zobaczy, ze dwa hasła
są takie same, to nie będzie wiedział, jacy użytkownicy mają takie same
hasła.

> - user nie moze miec dostepu do kodu zrodlowego programu (odpada
> impelementacja w jezyku skryptowym), bo "sol" jest w nim w postaci jawnej,
> a nawet jesli to jakos "zaczarujesz" i ukryjesz jakos w kodzie, to mozna po
> prostu fragment kodu (tym z "czarami") uzyc bezposrednio do metody
> slownikowej
Dlaczego nie można tak zrobić z losową solą?

> - jesli implementacja jest na przyklad w C, to mimo wszystko user moze
> uruchomic ten program pod debuggerem i sledzic jego wykonanie
> (albo zresourcowac kod lub podejrzec "sol" w binarce)
A w przeciwnym rozwiązaniu ma sól zapisaną razem z hasłem - czyli jeszcze
łatwiej ją wyciągnąć niż z pliku binarnego. No chyba że losowa sól leży na
innej maszynie, ale stała sól też może leżeć na innej maszynie.


> Po prostu - losowa "sol" moim zdaniem ma bardzo wiele plusow w stosunku do
> zakodowanej na twardo i moim zdaniem sol zakodowana na twardo wynika
> glownie z lenistwa programisty :D Oczywiscie to tylko moje zdanie - nie
> upieram sie, ze jest jedynym slusznym ;

Możliwe że masz rację, ja tego nie widzę. Mamy dwie sytuacje:
1) wyciekło zakodowane* hasło i losowa sól
2) wyciekło zakodowane* hasło i stała sól
I w jednym przypadku i w drugim odzyskujemy samo hasło burtforcem.

Kolejne dwie sytuacje:
1) wyciekło zakodowane* hasło, używano stałej soli która nie wyciekła
2) wyciekło zakodowane* hasło, używano losowje soli która nie wyciekła
I w jednym przypadku i w drugim odzyskujemy dwie rzeczy: hasło i sól,
przy pomocy burtforcem.

Kolejna sytuacja: wyciekło zakodowane* hasło, nie używano solenia:
1) Łamiemy przy pomocy tęczowych tablic.

*) znany jest algorytm solenia i kodowania.

W jakim miejscu popełniam błąd?

Pozdrawiam







)

do góry

On Wednesday, November 12, 2014 8:26:31 PM UTC+1, Borneq wrote:
> W dniu 2014-11-12 o 19:59, Piotr pisze:
> > Przy losowych "solach" mozesz userowi udostepnic program hashujacy (moze
> > byc nawet zrodlowka czy program napisany w jezyku skryptowym - nie musisz
>
> Ale losowa sól musi być taka sama przy tworzeniu każdego hasha jak i
> przy sprawdzaniu. Jeśli nie jest zaszyta w kodzie programu, powinna być
> w pliku konfiguracyjnym i nie zmieniana?
Jeśli coś z tego wszystkiego rozumiem, to chodzi o porównanie dwóch
rzeczy:
1) każde hasło ma tę samą losową sól
2) każde hasło ma inną losową sól.
Pozdrawiam

do góry

On 2014-11-12, Borneq <b...@a...hidden.pl> wrote:
> W dniu 2014-11-12 o 19:59, Piotr pisze:
>> Przy losowych "solach" mozesz userowi udostepnic program hashujacy (moze
>> byc nawet zrodlowka czy program napisany w jezyku skryptowym - nie musisz
>
> Ale losowa sól musi być taka sama przy tworzeniu każdego hasha jak i
> przy sprawdzaniu. Jeśli nie jest zaszyta w kodzie programu, powinna być
> w pliku konfiguracyjnym i nie zmieniana?

Widziałeś kiedyś zawartość /etc/shadow? Czym jest twoim zdaniem ciąg po
drugim dolarze w "$1$...$........"? Sól nie musi być nieznana, wystarczy
że będzie inna dla każdego hasła.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Wednesday, November 12, 2014 11:24:20 PM UTC+1, Stachu 'Dozzie' K. wrote:
> Widziałeś kiedyś zawartość /etc/shadow? Czym jest twoim zdaniem ciąg po
> drugim dolarze w "$1$...$........"? Sól nie musi być nieznana, wystarczy
> że będzie inna dla każdego hasła.
Wystarczy do czego? Jak wygląda kompletna lista konkretnych zalet względem
soli takiej samej dla każdego hasła? Może ja zacznę tę listę, a Ty
ją skorygujesz i rozbudujesz - jeśli mogę prosić.

1) Nie można ustalić kto ma takie same hasła na podstawie listy
loginów i zakodowanych haseł.
2) Nie można łamać wszystkich haseł na raz.

Co jeszcze? Co dalej?

Pytanie: czy w obu przypadkach użycie tęczowych tablic mija się z celem?

Pozdrawiam

do góry

On Wednesday, November 12, 2014 11:48:57 PM UTC+1, M.M. wrote:
Jeszcze cytat z wiki:
[
Biorąc pod uwagę, że złodziej haseł może posłużyć się tęczowymi tablicami, możemy
powiększyć dane do takiego rozmiaru, przy którym używanie tęczowych tablic przestanie
mieć sens. Np. gdy tęczowe tablice nadają się do łamania skrótów, które powstały od
danych mających od 1 do 8 bajtów, wystarczy dodać 8 bajtów soli, aby uniemożliwić ich
stosowanie. Nawet jeśli złodziej zna sól, nie będzie w stanie jej ominąć.
]
Nic tutaj nie piszą o tym, że dla każdego hasła musi być inna sól, aby
posłużenie się tęczowymi tablicami było niemożliwe. Piszą tylko, że
wystarczy powiększyć dane. Albo na wiki jest nieścisłość, albo argument z
tęczowymi tablicami odpada. Kiedyś czytałem inny artykuł, też nie pisali
nic o tym, że wszędzie musi być inna sól. Ale nie wiem, może to ogólnie
panujący błędy pogląd.

Pozdrawiam

do góry

On 12.11.2014 23:48, M.M. wrote:
> On Wednesday, November 12, 2014 11:24:20 PM UTC+1, Stachu 'Dozzie' K. wrote:
>> Widziałeś kiedyś zawartość /etc/shadow? Czym jest twoim zdaniem ciąg po
>> drugim dolarze w "$1$...$........"? Sól nie musi być nieznana, wystarczy
>> że będzie inna dla każdego hasła.
> Wystarczy do czego? Jak wygląda kompletna lista konkretnych zalet względem
> soli takiej samej dla każdego hasła?

Trzeba podejść do sprawy paranoicznie. Za zol uzywamuy liczby
wygenerowanej dla hasła użytkownika i liczby zapisanej w kodzie.
;-)


> Może ja zacznę tę listę, a Ty
> ją skorygujesz i rozbudujesz - jeśli mogę prosić.
>
> 1) Nie można ustalić kto ma takie same hasła na podstawie listy
> loginów i zakodowanych haseł.
> 2) Nie można łamać wszystkich haseł na raz.
>
> Co jeszcze? Co dalej?

A nie wystarczy? Raz unikamy ataku statystyką i słownikiem,
którego koszt jest praktycznie darmowy, za drugim zwiększamy
koszt obliczeniowy ataku *liczba użytkowników, czyli potencjalnie
miliony razy.


pzdr
bartekltg

do góry

On 13.11.2014 00:12, M.M. wrote:
> On Wednesday, November 12, 2014 11:48:57 PM UTC+1, M.M. wrote:
> Jeszcze cytat z wiki:
> [
> Biorąc pod uwagę, że złodziej haseł może posłużyć się tęczowymi tablicami, możemy
powiększyć dane do takiego rozmiaru, przy którym używanie tęczowych tablic przestanie
mieć sens. Np. gdy tęczowe tablice nadają się do łamania skrótów, które powstały od
danych mających od 1 do 8 bajtów, wystarczy dodać 8 bajtów soli, aby uniemożliwić ich
stosowanie. Nawet jeśli złodziej zna sól, nie będzie w stanie jej ominąć.
> ]
> Nic tutaj nie piszą o tym, że dla każdego hasła musi być inna sól, aby
> posłużenie się tęczowymi tablicami było niemożliwe. Piszą tylko, że
> wystarczy powiększyć dane. Albo na wiki jest nieścisłość, albo argument z
> tęczowymi tablicami odpada. Kiedyś czytałem inny artykuł, też nie pisali
> nic o tym, że wszędzie musi być inna sól. Ale nie wiem, może to ogólnie
> panujący błędy pogląd.

Wydaje mi się, że autor miał na myśli to, że przygotowanie takiej
tablicy dla porządnej kryptograficznej funkcji skrótu trochę trwa,
zakłada więc, że taką tablicę przygotowujemy raz i potem tylko
chcemy używać. Użycie _jakiejś_ odpowiednio długiej soli uniemożliwia
atakującemu zbudowanie tablicy dekodującej na zapas. Może ją zacząć
budować dopiero, gdy sol wycieknie.

Tele na temat 'co autor miał na myśli'. Klikam na dłuższą wersję:

The salt value is not secret and may be generated at random and
stored with the password hash. A large salt value prevents
precomputation attacks, including rainbow tables, by ensuring that
each user's password is hashed uniquely. This means that two users
with the same password will have different password hashes (assuming
different salts are used). In order to succeed, an attacker needs to
precompute tables for each possible salt value. The salt must be large
enough, otherwise an attacker can make a table for each salt value.

Tu już zalecają różne sole. Przemykają nieco nad uzasadnieniem,
czyli tym, że nie tylko mamy większy koszt _wcześniejszego_
przygotowania (co było już przy wspólnej _tajnej_ soli) ale
i koszt ataku w momencie wypłynięcia jest *liczba użytkowników
raza mniejszy.

To ostatnie zdanie musze doprecyzować. Oczekiwany koszt w obu
przypadkach jest liniowy. Tylko jeśli znamy sol, która jest wspólna
dla wszystkich haseł, hashując jakąś propozycję hasła mamy
prawdopodobieństwo

liczba_haseł_w_bazie/liczba_potencajlnych_haseł

na trafienie w jakis hash. Zamiast po prostu
1/liczba_potencajlnych_haseł
jak będzie przy różnych solach.

pzdr
bartekltg

do góry