Jak wspomniałem we wcześniejszym poście, nie należy umieszczać hasła w bazie danych w postaci jawnej. Zabezpiecza nas to przed uzyskaniem dostępu do haseł przez osoby nieuprawnione. Sam hash nie stanowi jednak pełnego zabezpieczenia. Dlaczego?
Słabym punktem w bezpieczeństwie haseł jest użytkownik. Ułoży on sobie dajmy na to hasło „Andzia” i uważa się za bezpiecznego. Tymczasem włamywacz po dostaniu się do bazy danych, będzie miał hashe wszystkich haseł użytkowników. Część z nich da sobie w tym momencie spokój. Jednak nie bądźmy zbytnimi optymistami – znikoma część. Jak już pisałem, programiście potrzebna jest zdrowa doza paranoi. Wracając do naszego włamywacza. Podstawową metodą działania będzie tutaj atak słownikowy lub brute-force. W przypadku „zdobytej” bazy danych są one dużo prostsze niż w przypadku formularza logowania – wystarczy przygotować sobie wcześniej lub ściągnąć tablicę hashy przygotowaną na podstawie słownika lub powiedzmy kombinacji do 8 znaków. W tym momencie porównujemy zahashowane hasło z bazy danych z naszą listą gotowych hashy. Gdy trafimy – znamy hasło ofiary. Najczęściej pasujące również do konta poczty elektronicznej i Bóg jeden wie do czego jeszcze.
Część serwisów stosuje jako zabezpieczenie hashowanie wielokrotne. Np. [cci]md5(sha1($haslo));[/cci]. Jest to pewne utrudnienie dla atakującego, choć prawdopodobnie, jeżeli uzyskał dostęp do bazy danych, jest on także w stanie uzyskać dostęp do kodu serwisu i sprawdzić sekwencję hashowania. Jeżeli nie to pozostają mu przygotowane tablice sekwencji hashujących.
Najlepszym zabezpieczeniem jest hashowanie czegoś więcej niż samego hasła użytkownika. Niektóre systemy dodają do hasha sól definiowaną w pliku konfiguracyjnym. Jest to dosyć kiepskie rozwiązanie ponieważ dostęp do kodu źródłowego wystarczy, by przygotować kolejną tablicę hashy gotowych do szukania w bazie. Można za to np. hashować ciąg znaków składający się z hasła + adres e-mail. Daje to przeciętnie długość ok. 25 znaków. Dla porównania, od ok. 10 znaków przygotowanie tablicy predefiniowanych hashy i porównywanie ich z bazą staje się dość mocno problematyczne – mówimy o biliardach kombinacji. Stosuje się tu praktycznie już tylko o ataki słownikowe. Hash zmienny ma jeszcze jedną zaletę – by go złamać, tablicę hashy trzeba generować osobno dla każdego rekordu w bazie. Z taką metodą przechowywania nasi użytkownicy mogą czuć się naprawdę bezpiecznie.
Leave a Reply