W dniu sobota, 29 listopada 2014 20:58:19 UTC+1 użytkownik Edek napisał:
> On Wed, 12 Nov 2014 02:30:46 +0000, Piotr wrote:
>
> > Dnia 12.11.2014 M.M. <m...@g...com> napisał/a:
> >> On Wednesday, November 12, 2014 12:31:11 AM UTC+1, bartekltg wrote:
> >>
> >>> > Moim zdaniem przez losowe osolenie, mozna co najwyzej uniemozliwic
> >>> > lamanie calej bazy na raz, czyli lamacz musi kazde haslo po kolei.
> >>> > Czy myle sie?
> >>>
> >>> Przecież dokładnie to Ci napiałem w pierwszym poście
> >> Zgadzam sie ze wszystkim co mi napisales w pierwszym poscie. Niezgadzam
> >> sie tylko z tym, ze uzycie tego samego zaburzenia do wszystkich hasel
> >> jest duzo gorszym rozwiazaniem niz za kazdym razem losowego.
> >
> > Jesli masz dostep do zaszyfrowanych hasel, to jest duzo gorszym. Przy
> > wspolnym zasoleniu po pierwsze trywialne jest sprawdzenie kto ma takie
> > samo haslo jak Ty, a po drugie trzeba znacznie mniejszej mocy (ilosci
> > obliczen)
> > aby haslo zlamac. Wezmy dla przykladu haslo 8-bajtowe (64-bit) i sol
> > 8-bajtowe,
> > jesli kazdy ma losowa sol, to masz 2^128 mozliwosci do sprawdzenia dla
> > brute-force. Jesli masz wspolna "sol", to masz tylko 2^64+2^64=2^65
> > mozliwosci a to duzo, duzo mniej. Zapytasz czemu 2^64+2^64? Chociazby
> > mozna podejsc do tego w ten sposob, ze lamiesz najpierw "sol" (swoje
> > haslo znasz,
> > i wynik dzialania hasha na tym hasle tez znasz, wiec crackujesz tylko
> > bity "osolenia" a wiec 2^64 wariantow), jak juz znasz konfiguracje bitow
> > soli,
> > to potem lamiesz czyjes haslo wiedzac, jaka jest konfiguracja bitow
> > "soli" czyli pozostaje Ci tez "tylko: 2^64 wariantow do sprawdzenia.
> > Roznica jest jak widzisz kolosalna.
>
> Dokładnie. Ludzia i ludzie: kryptografia opiera się na dwóch rzeczach
> jak już matematycy coś wysmażą.
> 1. Mechaniźmie, jak asymetryczne, symetryczne, one way hash, paru
> innych. One określają co z czego można mieć (albo nie można).
> Matematyczne słabości oczywiście zmieniają sposób patrzenia na to
> co można a co nie.
> 2. Pytaniu, co kto wie, skąd i od kiedy. Na przykład przy
> logowaniu zakłada się, że dana osoba zna hasło, nikt inny nie zna.
>
> W hashu z solą:
>
> - user zna hasło
> - system zna sól i hash(sól+hasło)
> - atakujący z zewnątrz nie zna ani soli ani hasła
> - atakujący, który przejął serwer zna i sól i hash, chce znać hasło
>
> To ostatnie jest ciekawe: wykradając /etc/shadow - mając dostęp
> do serwera czy tylko wykradając plik - można odpowiednio włamać
> się do innych serwerów lub do tego serwera też, o ile odpowiednio
> user używa tego samego hasła gdzie indziej lub też na tym serwerze.
>
> I tylko dlatego się soli. Stała sól ma pewien sens, w końcu
> o ile nie jest znana atakującemu ma przewagę nad solą przyklejoną
> do hasha, która staje się znana wraz z hashem. Ale ma wymienione
> wady, da się wygenerować hashe no i gratis znać hasła identycznych
> hashy (z identycznego hasła przy identycznej soli powstaje identyczny
> hash).
>
> Nie wydaje mi się żeby to wyliczenie Bartka dotyczące czasu używania
> tablic było sensowne: można wyliczone hashe ułożyć w b-tree i zrobić
> lookup log(n) po hashu z hasła usera. Nie da się?

Nie, nie da się. To do cholery nie problem przeszukiwania! ;-)
Nie da się bo nie masz takiej pojemnośći, by
wszystkie hashe (z malutkiego przykladu) trzymać.
Dlatego korzysta się z tablic tęczowych, to tradeof pomiędzy
objętością bazy danych a potrzebną mocą.
Myślisz o np 10^11 łańcuchach hashy, każdy mający 10^9
elementów. Na dysku trzymasz tylko pierwszy i ostatni
element łancucha (coś rzędu wspomnianego terabajta).

Jeśli teraz dostajesz zadanie, rozbij hash X, liczysz
łańcuch od niego, i dla każdego elementu łancucha
sprawdzamy, czy nie jest elementem końcowym któregoś
z danych na dysku.

I tu niespodzianka, Ty proponujesz robić to w log[n]
odczytach z dysku, a ja zaproponowałem robić to
_jednym_ odczytem z dysku;p Bardzo optymistyczne
oszacowanie;-)

pzdr
bartekltg