Bezpieczeństwo MD5 (i głupota ludzka)

Jak najlepiej przechowywać kody dostępu w bazie danych? Oczywiście tak, aby ktoś kto uzyska autoryzowany (bądź nieautoryzowany) dostep do naszych danych , nie poznał tych kodów.Wiekszość programistów (w tym również do niedawna ja) polecała prosty algorytm:

1. Podczas dodawania nowego użytkownika do bazy zapisuj hash hasła, a nie samo hasło.

2. Podczas logowania użytkownika pobierz hasło, oblicz hash i porównaj z hashem zapisanym w bazie.

Jaki algorytm wybrać? “Oczywiście” najpopularniejszy - MD5. Czy jednak mamy wtedy gwarancje, ze majac dostep do bazy nikt nie pozna naszego hasła?

O bezpieczeństwie MD5 bylo jakis czas temu głośno. Pięć lat po opracowaniu algorytmu , w 1996 Hans Dobbertin zaprezentowal analizę kolizji w MD5 . Naprawdę głośno zrobilo sie jednak 8 lat później - marcu 2004 - dzieki projektowi MD5CRK . Był to zbiorowy projekt , który miał na celu wykazanie mozliwosci wyznaczenia conajmniej jednego kodu, ktorego hash bedzie identyczny z zadanym dysponujac odpowiednim zapleczem sprzętowym (uczestnicy projektu udostepniali czesc mocy obliczeniowej własnych komputerów poprzez internet). Projekt zakończył sie oczywiście sukcesem - jednak niewiele z tego wynikało. Ciężko bowiem wyobrazić sobie aby ktoś do “złamania” pojedyńczego hasła zorganizował 6000 komputerów które pracowały by non stop przez 3 tygodnie.

2004 rok nie byl szczęśliwy dla najpopularniejszego algorytmu - 17 sierpnia 2004 wyniki swoich badań opublikowali chińscy naukowcy: Xiaoyun Wang, Dengguo Fen, Xuejia Lai i Hongbo Yu. Algorytm który opracowali umożliwia wygenerowanie identycznego hasha na klastrowym komputerze IBM P690 godzinę.

Wciaż jednak cieżko mówić o “szybkim” fałszowaniu md5-hashów - wszak P690 to z tego co pamietam 32-procesorowa maszyna . Jest to jednak dużo prostsze niż kiedyś (i w zastosowaniach stricte biznesowych stosowanie tego algorytmu można porównać z budowaniem budynku z brył lodu na sacharze - moze nawet to drugie ma wiecej sensu) .

Dlatego jesli ktos obawia sie tego typu ataków, powinnien przerzucić się na SHA-256 lub SHA-512 . Moją implementacje SHA-512 w C++ , C# oraz PHP (dla wersji >= 5.1.2 są też gotowe rozwiazania) przedstawie jesli starczy czasu za kilka dni.

Tyle tytułem tego przydługawego wstępu - bo to co poniżej napisze dotyczy każdego algorytmu hashującego. Nieistotne, czy mowimy o md4, md5, sha1, sha256, sha384, sha51,2 ripemd128, ripemd160, whirlpool, tigerach, haval’ach, czy starym dobrym crc.

Najsłabszym ogniwem jest zawsze człowiek - i choć brzmi to śmiesznie i oklepanie to zaraz to udowodnie.

Poprosiłem znajomego prowadzącego duży serwis społecznościowy o udostępnienie 100 losowych md5 hashy. A następnie porównalem ją z bazą ~50 milionów innych hashy. Zajęlo mi to (tylko dlatego, ze nie mialem zadnego narzedzia automatyzującego) około 30 minut.

Jest to oczywiscie modyfikacja metody brute-force. Wielu twierdzi, ze brute-force to metoda zasobożerna, która daje mierne rezultaty. Co jednak, gdy chcemy znaleźć ciąg dajacy taki sam hash jak ten który znamy?

100 haseł, 30 minut, wiec średnio na jedno hasło miałem 20 sekund. Jak myślicie, ile hashów udało się dopasować?

1? 2? 5? 10?

35 haseł, 35 hashy, 35 %. Czy to dużo? Zakładając , że w serwisie byloby 100 000 użytkowników oraz rozkład ‘prostych’ haseł jest równomierny w całym przedziale  (a tak prawdopodobnie jest), to sprawdzajac  wszystkie hashe uzystałbym 35000 haseł. Czy to groźne? Zależy od serwisu. Jednak warto sie zastanowić, jaki procent osób używa tego samego  hasła w poczcie elektronicznej, aukcjach internetowych, w banku, komunikatorze i wielu innych?

Pewnie pomyślicie o jakimś pojedyńczym, lub ułamku procenta.  Jednak zapewniam,że widzac te hasła (gdzie wiele z nich to własne imiona, lub kolejne klawisze z klawiatury). Nie zdziwilbym sie, gdyby ponad 50% tych osób uzywala tych samych haseł wszedzie. Jednak nawet jeśli bezpiecznie założymy , że 5% stosuje te same hasła, to dzieki temu moge miec do dyspozycji prawie 2000 haseł , które pozwolą mi się zalogować w różne miejsca.

Oczywiście (podkreślam to jeszcze raz) nie jest to wada algorytmu - a czynnika ludzkiego. Zdobycie takich haseł poprzez SQL Injection w wielu serwisach jest mozliwe (zwlaszcza w darmowych skryptach typu phpBB, gdzie dostepne sa gotowe narzedzia umozliwiajace praktycznie łażenie po całym serwerze) . Tak więc drodzy użytkownicy - używajcie TRUDNYCH do złamania haseł. Hasło trudne to nie nic nie znaczący ciąg liter, lub cyfr. Hasło trudne to nie hasło “fswg23″ . Używajcie w hasłach znaków specjalnych, hasło “marta” trudne nie jest, ale “!@marta@!” złamać dużo trudniej. A czy dużo trudniej takie hasło zapamiętać? Nie sądze.

A programiści - zabezpieczcie bazy tak, aby nikt sie do nich nie dostał. Używajcie małopopularnych funkcji hashujacych. Baz hashów do md5() i sha1() jest naprawde dużo. sha512 jeszcze nie spotkałem. Choć faktem jest, że stworzyć taką to nie kłopot. Można również przed zahashowaniem dodać kilka niestandardowych znaków na początek i koniec hasła:

md5(”;{”.user_password.”};”);

Prosta operacja, a problem gotowych baz hashy jest mocno ograniczony.  Sposobów jest naprawde wiele - ogranicza nas wylacznie wyobraźnia.