Zwykłym sposobem przechowywania hasła jest użycie funkcji skrótu hasła, ale sól to wcześniej. Ważne jest, aby "solić" hasło, aby obronić się przed tęczowym stołem ataki.
Twój stół powinien więc wyglądać mniej więcej tak
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |[email protected]|13%!#tQ!#3t...|
| |... |... |
Sprawdzając, czy dane hasło pasuje do użytkownika, należy połączyć sól z podanym hasłem i obliczyć funkcję skrótu ciągu wynikowego. Jeśli wynik funkcji mieszającej pasuje do hash kolumna - jest to prawidłowe hasło.
Ważne jest jednak, aby zrozumieć, że pomysł salt-hash ma konkretny powód — aby uniemożliwić każdemu, kto ma dostęp do bazy danych, poznanie hasła (odwrócenie wyniku funkcji skrótu jest uważane za trudny problem). Na przykład DBA banku nie byłby w stanie zalogować się na twoje konto bankowe, nawet jeśli ma dostęp do wszystkich kolumn.
Powinieneś również rozważyć jego użycie, jeśli uważasz, że Twoi użytkownicy będą używać poufnego hasła (na przykład hasła do konta Gmail) jako hasła do Twojej witryny.
IMHO nie zawsze jest to zabezpieczenie, które jest potrzebne. Więc powinieneś pomyśleć, czy tego chcesz, czy nie.
Zobacz ten artykuł dobre podsumowanie tego mechanizmu.
Aktualizacja: Warto wspomnieć, że w celu dodatkowego zabezpieczenia przed atakiem ukierunkowanym w celu cofnięcia hasha poszczególnych haseł, należy użyj bcrypt , co może być dowolnie trudne do obliczenia. (Ale jeśli naprawdę nie boisz się tajemniczego mężczyzny w czerni celującego w twoją konkretną bazę danych, myślę, że sha1 jest wystarczająco dobre. Nie wprowadziłbym kolejnej zależności do mojego projektu dla tego dodatkowego zabezpieczenia. To powiedziawszy, nie ma powodu, aby nie używać sha1 100 razy, co dałoby podobny efekt).
