Cztery poziomy trudności
Masz serwis on-line, a na nim konta użytkowników, którzy mogą logować się do serwisu za pomocą nazwy użytkownika i hasła.
Co zrobić, żeby w razie włamania na serwer (ewentualnie zatrudnienia nieuczciwego administratora) zminimalizować szanse na odgadnięcie / złamanie haseł użytkowników?
Pokażę teraz cztery podejścia: zacznę od najbardziej naiwnego, a skończę na całkiem zaawansowanym.
Hasło
Przechowywanie haseł w tabeli bazy danych (lub w pliku tekstowym) to najgłupsza rzecz pod słońcem. Jeżeli włamywacz tam zajrzy, ma wszystkie hasła bezwysiłkowo.
Hasz hasła
Tu już jest ciut lepiej: włamywacz zna tylko hasz, więc żeby odgadnąć na jego podstawie hasło musi albo próbować haszowania różnych haseł i sprawdzać za każdym razem, czy trafił, albo odwrócić kota ogonem i poszukać hasza w Google (hasze popularnych haseł są powszechnie dostępne), dzięki czemu bez większych problemów pozna hasła użytkowników niefrasobliwych.
Posolony hasz hasła
Tu już jest całkiem nieźle. Przechowując hasz hasła wraz z solą (o soleniu haseł pisałem tutaj: !) w zasadzie eliminujemy ryzyko znalezienia takiego hasza w Google, a więc jedyne, na co może sobie pozwolić włamywacz, to brute-force, czyli próbowanie kolejnych haseł w nadziei trafienia na to właściwe.
Polosony hasz hasła wyliczony w wielu rundach
To zdecydowanie najbezpieczniejsze podejście: przy zakładaniu konta przez użytkownika generujemy ziarenko soli, dołączamy je do hasła, generujemy hasz, do hasza dołączamy znów to samo ziarenko soli, generujemy z tego kolejny hasz i tak dalej, wiele, wiele razy (na przykład 50000 razy). Dzięki temu stosując brute-force włamywacz będzie musiał spędzić naprawdę dużo czasu na próbie odgadnięcia każdego pojedynczego hasła, dzięki czemu łamanie nawet prostych haseł może zająć nieuczciwemu administratorowi wiele, wiele lat.
Komentarze