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: !klik!) 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.


Zapisz się
Powiadom o
guest
0 komentarzy
Inline Feedbacks
Zobacz wszystkie komentarze
0
Zapraszam do skomentowania wpisu.x
()
x