"blad" <blad201@_W_Y_T_N_I_J_sezam.pl> writes:

>> Ile razy mozna przypominac ze w przypadku PINu nie da sie tego tak
>> zrobic?
>>
>> PIN jest zbyt krotki.
>
> na tą okoliczność wymyślono "salt", po naszemu "ziarno",
> dokładane do haseł przed hashowaniem

Nie, to nie na to okolicznosc, na to nie ma zadnej rady, bo nawet
teoretycznie wiadomo ze kazdy taki przypadek jest mozliwy do zlamania
w ciagu ulamka sekundy.


Salt sluzy do tego, by (w przypadku hasel o "normalnej" dlugosci
i liczbie roznych mozliwych znakow - typu np. > 10 znakow ASCII)
utrudnic odwracanie zaszyfrowanych hasel metodami innymi niz brute
force (np. rainbow tables).

Innymi slowy, nie wystarczy nam juz pojedyncza tabela (uzyskana
np. metoda slownikowa) i porownywanie zaszyfrowanych hasel:

aaa8dfssdf908se45o2i3h4kj234 alamakota
aabfff9e8r34i5krl324m4345309 rambo3rulez
aac98asd09f8spdoti3lk4j5l333 &sk4b1+c($H*)AMZBzxdtr4

itd. - tylko nalezaloby miec np. 4096 takich tabelek.

Przy okazji salt powoduje, ze dwa jednakowe hasla (np. dwoch userow)
nie sa juz (zwykle) jednakowe po "zaszyfrowaniu".


Z tym ze niestety w przypadku hasel bank (serwer itd) zawsze ma dostep
do niezaszyfrowanych wersji, niezaleznie od saltow i dlugosci/jakosci
hasel - przynajmniej w chwili ich wprowadzania przez usera.
Na to pomaga kryptografia asymetryczna, jesli jest oczywiscie dobrze
zrobiona i jesli uzytkownik jest swiadomy.
--
Krzysztof Halasa