[PHP][Bezpieczeństwo] Posolić, czy spieprzyć?

Hasła można dobrze posolić, albo totalnie sprawę spieprzyć. Prawidłowe posolenie hasła może być dla mało doświadczonej osoby dość niejasne. A czym jest w ogóle to posolenie? Otóż jest to dodanie do hasła jakiegoś ciągu znaków (soli), a następnie dopiero zahaszowanie takiego połączonego ciągu i dopiero zapisanie go w bazie. Co to daje? Otóż daje to to, że nawet po wycieku hashy z bazy nie da się z nimi zbytnio nic zrobić, o ile zostały dobrze posolone i potraktowane dobrym, silnym algorytmem. A dlaczego? Ano dlatego, że nie da rady ich porównać z tablicami, które zawierają listę hashy odpowiadającą wartościom niezahashowanym, tzw. tablicami tęczowymi. Nie znaczy to oczywiście, że nie da się takiego hasła złamać, dobre posolenie tworzy jednak jeden kolejny problem do pokonania, a więc zmniejsza prawdopodobnieństwo dla złamania hasła.


Mały przykład:
Hasło: 12345
Jego hash MD5: 827ccb0eea8a706c4c34a16891f84e7b

Hasło: 12345słoneczkoJestNaDole
(gdzie "słoneczko..." jest solą)
Hash całości: 90a39c12790b33413ae37249ef9b1ac6

Lepiej? Na oko tak, ale nie do końca. Słowa słownikowe wciąż występują i teoretycznie taka sól jest w jakiś sposób możliwa w wystąpieniu.
A co jeśli damy np. taką sól: xGwtdhT537$5#943293-2HF25SDF&^%sh@g?
Tego raczej w słowniku już nie będzie, w połączeniu z naszym hasłem, czyli 12345 da nam to: 12345xGwtdhT537$5#943293-2HF25SDF&^%sh@g, co jako hash da nam:
040b6f4721808f569098ee6dd19e2c8a.

Zaznaczam tutaj jedną ważną sprawę - operujemy jedynie na MD5 i sprawę drugą - takiego hasła w tablicy nie znajdziemy, oraz trzecią - MD5 to dość słaby algorytm.
Pomińmy teraz sprawę drugą i zostawmy jedynie pierwszą i trzecią. Co nam zostaje? Zostaje nam mimo wszystko słaby hash, mimo iż teoretycznie "na oko" niemożliwy do złamania, to jednak możliwy i to jak najbardziej techniką brute-force, która notabene łączy się z tablicami. Kwestia czasu (obecnie dość małego) i mocy obliczeniowej. W dobie płatnych za wynajem chmur obliczeniowych dość krótki czas na złamanie przez podstawianie. Plus dochodzi nam jeszcze jeden aspekt - sprawa kolizji. Matematycznie rzecz biorąc, może zdarzyć się, że dwa różne hasła mogą dać identyczną funkcję skrótu. Dodajmy jeszcze jeden ważny aspekt - każde złamane hasło zostanie dodane do tablicy. Na podstawie ogarniętych haseł można mniej więcej określić, oddzielić część "jawną" hasła od jego soli. Wszystko to jedynie kwestia mocy obliczeniowej.

Jak żyć?

Jak możemy więc zwiększyć bezpieczeństwo (wyobrażając sobie, że pracujemy wciąż na złamanym MD5)? Możemy dokładać do pieca. W jaki sposób?
A czemu sól nie miałaby być generowana dynamicznie? A nie jako stała wartość?
Wyobrażmy sobie teraz taką opcję: użytkownik podczas rejestracji podaje swoje hasło - hashujemy je i dodajemy do bazy. Co stoi na przeszkodzie, żeby do tego hasha nie dodać jeszcze hasha zrobionego z jego emaila połączonego z zahashowanym adesem IP z jakie się rejestrował i zapisaniu tego IP swoim tylko znanym algorytmem szyfrowania, a następnie podczas logowania - użytkownik loguje się, a nasza funkcja odwraca proces? Dodatkowo dodać do tego kilka elementów losowych, zapisanych przy użytkowniku (bo muszą być zapisane, ale niekoniecznie nikt nie musi wiedzieć, które to aspekty). Pole do popisu jest duże. Zaznaczam, że rozmawiamy jedynie o starym MD5, ale tyczy się to też mocniejszych algorytmów.

To tak tytułem eksperymentu - krótki wpis, żeby zobaczyć jakie macie pomysły, bo nic tak nie uczy jak własne podejścia.
Zapraszam do dyskusji, a niebawem obszerniejszy artykuł w tym temacie.