Nudy: znowu o przechowywaniu haseł

W BackTrack4 R2 jest plik bt4-password.txt zawierający ponad 3 miliony linii (potencjalnych haseł)...

Przy pomocy prostego skryptu w Pythonie sprawdzenie wszystkich tych haseł zajmuje w zależności od użytego algorytmu w przybliżeniu:

Dodając do tego salt , wartości te wynoszą:

Python w tym przypadku jest językiem bardzo niewydajnym, same operacje kryptograficzne to jedynie ułamek podanych czasów. Nawet w tym przypadku wyliczenie ponad 3 milionów hashy SHA512 z saltem trwa krótko, tylko dwa razy więcej niż “czyste” MD5. Zresztą takich wyników można się było spodziewać choćby po danych o wydajności w operacjach kryptograficznych podawanych przez openssl (patrz: Coś mocniejszego niż MD5).

To tak w komentarzu do kolejnego wycieku (patrz: Wpadka Mozilli – wyciek danych użytkowników serwisu z dodatkami do Firefoksa). Niespodzianka – MD5 nie jest źródłem wszelkiego ZŁA. A salt nie rozwiązuje wszystkich problemów, o czym już zresztą pisałem (ponownie patrz: Coś mocniejszego niż MD5).

Tak, przechowywanie haseł bez użycia salt jest złym pomysłem. W takim przypadku atakujący może łamać (sprawdzać) hasła w sposób bardzo efektywny, między innymi stosując rainbow tables. Akurat kwestia użytego algorytmu (funkcji skrótu) jest w tym przypadku drugorzędna. Przygotowanie tablic dla SHA512 będzie (z grubsza) dwa razy bardziej kosztowne, niż dla MD5. Nie jest to bariera nie do przejścia. Z drugiej strony długie, złożone hasło będzie praktycznie nie do złamania , niezależnie od wybranej funkcji skrótu. MD5 ma kolizje? Oczywiście, ale to wcale nie znaczy, że znalezienie ciągu danych (hasła) dającego z góry założony hash jest zadaniem trywialnym. A może jest? Jakie hasło może dać takie MD5: c28e6e726a019dc272615149b4d320f5? Dodam, że SHA1 tego hasła to 05fa4d95ecd1fa0fee02f59bbe85a132bf248e4b.

Żeby było jasne, nie twierdzę, że przy przechowywaniu hasła należy stosować MD5. Zwracam uwagę, że użycie innego algorytmu niż MD5 nie powoduje, że problemy “typowe” dla MD5 nagle przestają istnieć. Z drugiej strony przechowywanie hasła w MD5 nie implikuje tego, że każde hasło zostanie złamane (w sensownym czasie oczywiście).

Co daje salt? Jedna sprawa – salt jest jawny. Jawny w tym sensie, że musi być przechowywany razem z końcowym hashem, bo w przeciwnym razie nie będzie możliwości sprawdzenia, czy wpisane hasło jest prawidłowe. Oznacza to mniej więcej tyle, że w przypadku “wycieku” bazy haseł atakujący (najprawdopodobniej) dysponuje nie samymi hashami, ale również odpowiadającymi im saltami. Czyli proste, słownikowe hasło będzie równie łatwe do złamania w następujących przypadkach:

MD5: 8cd3bea6b7344c2920c9861e45aa7c9a SHA1: 863248e1be0e1852d4363c8fb12da101d852e112 SHA1(salt+password): 796d948b8e45c53c49ef43ad940ba068 6a3a2a06061e92a294b4e41dd759b159f664dcc4

Te powyższe hashe każdy sobie może spróbować połamać...

Salt daje głównie dwie korzyści:

Dodatkowo jeśli dysponuje się hashami haseł dla n użytkowników konieczne jest n-krotne sprawdzenie danego hasła (słownikowe, brute force), przecież każdy z hashy został wyliczony z użyciem innego salta. Czy jest to istotna różnica? Zależy. Jeśli łamanych jest kilkaset lub kilka tysięcy haseł – tak. Jeśli jednak obiektem ataku jest jedno lub kilka haseł, atak słownikowy czy atak brute force nie jest dużo bardziej kosztowny, niż atak na hashe haseł wygenerowane bez użycia soli.

Użycie soli nie gwarantuje, że hasło będzie nie do złamania. Słabe, słownikowe hasła nadal daje się łamać w sensownym czasie. Sensownym, czyli takim, w którym atakujący może ze złamanego hasła mieć jakąś korzyść.

Hasła powinny być hashowane przy pomocy algorytmu, który został specjalnie w tym celu zaprojektowany, i który jest kosztowny obliczeniowo. Oczywiście nawet wówczas łamanie hashy nadal będzie możliwe, koszt (obliczeniowy) takiego zadania będzie jednak zdecydowanie większy, niż ten, który uda się osiągnąć stosując SHA512 i absurdalnej długości salt.

Po co o tym (znowu) piszę? Bo być może po kolejnych informacjach na temat wycieku haseł przechowywanych z użyciem MD5 ktoś zabierze się do roboty i zdecyduje się na wprowadzenie zmian... Niech to już zrobi porządnie.

Oryginał tego wpisu dostępny jest pod adresem Nudy: znowu o przechowywaniu haseł

Autor: Paweł Goleń