Branżowe

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.


Hrabia Duszański Hrabia Henryk

Dodaj komentarz

avatar
  Subscribe  
Powiadom o
%d bloggers like this: