W dniu 2013-01-22 02:53, M.M. pisze:
> W dniu poniedziałek, 21 stycznia 2013 10:21:35 UTC+1 użytkownik yamma napisał:
>> No i jeszcze pasowałoby przedtem posolić, żeby z takich samych haseł nie
>> wyszły identyczne "hasze". Ja zazwyczaj solę GUIDem, który jest
>> identyfikatorem rekordu ale np. Microsoft w ASP.NETowym Membershipie tworzy
>> dodatkowe pole z losowo wygenerowanym ciągiem znaków.
>
> Określenia "posolić" używa się normalnie, czy tak sobie napisałeś?
> Ja dodaje losowe znaki w kilku miejscach oryginalnego ciągu, potem
> jakiś standardowy klucz sha, albo md5, albo nawet jakiś własny. Gdzieś
> czytałem że md5 został rozpracowany - nie wiem znaczy słowo "rozpracowany",
> ale tak czy inaczej do hashowania w poważnej kryptografii lepiej nie używać.

Zwróć uwagę na to, o czym prawie kulturalnie mówił Stachu
wczoraj a daniel rzucił linka. Jeśli poza bazą danych o hasłach
(hash i 'sól')wycieknie też metoda kodowania (a czemu ma nie
wyciec, skoro baza wyciekła, o ile wręcz nie jest jawna) to
jesteśmy podatni na atak przez ręczne md5 wszystkich możliwych
haseł. Jeśli nie są one zbyt długie, jest to robialne.

Sól daje to, że operację trzeba powtórzyć dla każdego użytkownika,
zamiast za jednym zamachem mieć odkodowanych wszystkich,
ale to niewielka pociecha, gdy np Ty jesteś celem;)


Różnica między
http://en.wikipedia.org/wiki/Cryptographic_hash_func
tion
a
http://en.wikipedia.org/wiki/Key_derivation_function


I to, na co koledzy zwrócili uwagę:
Modern password-based key derivation functions, such as PBKDF2
(specified in RFC 2898), use a cryptographic hash, such as MD5
or SHA1, more salt (e.g. 64 bits and greater) and a high iteration
count (often 1000 or more). NIST requires at least 128 bits of
random salt and a NIST-approved cryptographic function, such as
the SHA series or AES (MD5 is not approved).[5] There have been
proposals to use algorithms that require large amounts of computer
memory and other computing resources to make custom hardware
attacks more difficult to mount.


pzdr
bartekltg