Dlaczego warto solić hasła?
Jakiś czas temu podczas opisywania bezpieczeństwa funkcji hashujących pisałem jak solenie haseł zwiększa ich bezpieczeństwo. Celem tego działania miało być utrudnienie pracy tęczowym tablicom. Wiele osób uważa, że samo hashowanie haseł daje wystarczający poziom bezpieczeństwa – przykładowo porzucając MD5 na rzecz SHA-1 / SHA-2. Rozumowanie takie ma jedną drobną wadę, mianowicie nie potrzeba „złamać” hasha, aby poznać hasło użytkownika. Brzmi niedorzecznie?
Mając zrzut tabeli z użytkownikami wystarczy wykonać jedno proste zapytanie, aby wszystko stało się jasne:
SELECT * FROM users WHERE password = SHA1( login );
w wyniku wykonania powyższego zapytania otrzymamy listę użytkowników, których hasło jest identyczne jak login. Sposób wydaje się mało sensowny, bo kto pozwala podczas rejestracji na podanie takiego samego hasła jak loginu? Z drugiej strony w jak wielu serwisach można się spotkać z takim ograniczeniem?
Problem identyczności loginu oraz hasła jest na tyle poważny, że do uzyskania dostępu do czyjegoś konta nie jest potrzebne uzyskanie dostępu do bazy danych. Wystarczy stworzyć prostego crawlera, który pobierze listę użytkowników dostępnych w serwisie, a następnie spróbuje się zalogować podając znalezione loginy, jako dane logowania.
Tagi: hash, solenie, tęczowe tablice
Kategoria: Bezpieczeństwo, Logowanie
Ja osobiście zawsze solę hasło hashem generowanym dla każdego użytkownika. Przydatna sprawa, bo to o wiele trudniej złamać, no i dzięki temu nie mam żadnych problemów.
solić też trzeba z głową, żeby nie okazało się, że zupa była za słona ;-) najprostszym i zapewne najczęściej spotykanym sposobem solenia z wykorzystaniem unikalnej soli dla usera jest wrzucenie do tabelki dodatkowej kolumny z zapisaną wartością soli – i tu pojawia się pytanie: co daje nam takie rozwiązanie w przypadku SQLi, szczególnie, że zapewne ~100 % osób dodaje sól po haśle
gwoli ścisłości szersze wyjaśnienie powyższego komcia:
mamy tabelkę
id | username | password | salt
password = md5( haslo_usera + hash )
w powyższym przypadku napastnik znając sól oraz sposób tworzenie skrótu hasła może bez problemu wykonać atak brute-force na dowolne konto. pojawiającym się utrudnieniem jest konieczność dla każdego sprawdzanego hasła generować n skrótów, gdzie n to liczba użytkowników
Pytanie, jak wiele osób podaje taki sam login i hasło? Faktycznie, zabezpieczenie się przed takim postępowaniem jest banalnie proste. Jednak nigdy nie wpadłem na pomysł, by ktoś mógł zrobić coś takiego – przez co nigdy nie napisałem takiego zabezpieczenia. Trza by przetestować, warte sprawdzenia z czystej ciekawości :)
wszystko zależy od targetu serwisu; z ciekawości przed dodaniem notki sprawdziłem w jednym z serwisów, do których mam dostęp i wyszło w granicach 5%
I teraz każdy pisze crawlery do serwisów, które masz na swojej stronie w temacie „ostatnie prace” w celu znalezienia tych 5% ;]
Należałoby wymuszać na użytkowniku aby login był tak skomplikowany jak nakłada się na zasady tworzenia haseł – wtedy na pewno hasło ustawi sobie proste i nigdy login i hasło nie będą takie same ;]]
he he :) pisałem, że mam do tego serwisu dostęp co nie znaczy, że wyszedł spod mojego palca ;P
a co do skomplikowania loginu tak samo jak hasła to chyba z tym najlepiej radzą sobie serwisy, którego targetem są dziewczyny do 16 roku życia ;-))