Обичайният начин за съхраняване на паролата е да се използва хеш функция за паролата, но да се сол то предварително. Важно е да "солите" паролата, за да се защитите срещу rainbow table атаки.
Така че вашата таблица трябва да изглежда нещо подобно
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |[email protected]|13%!#tQ!#3t...|
| |... |... |
Когато проверявате дали дадена парола съвпада с потребител, трябва да свържете солта към дадената парола и да изчислите хеш функцията на резултантния низ. Ако изходът на хеш функцията съвпада с hash колона - това е правилната парола.
Важно е обаче да се разбере, че идеята за сол-хеш има конкретна причина - да попречи на всеки с достъп до базата данни да знае паролата на когото и да било (смята се за труден проблем да се обърне изход на хеш функция). Така например, DBA на банката няма да може да влезе в банковата ви сметка, дори ако има достъп до всички колони.
Трябва също така да обмислите използването му, ако смятате, че вашите потребители ще използват чувствителна парола (например паролата си за акаунта си в gmail) като парола за вашия уебсайт.
IMHO не винаги е необходима защитна функция. Така че трябва да помислите дали го искате или не.
Вижте тази статия за добро обобщение на този механизъм.
Актуализация: Струва си да се спомене, че за допълнителна сигурност срещу насочена атака за обръщане на хеша на индивидуалната парола, трябва да използване на bcrypt , което може да бъде произволно трудно за изчисляване. (Но освен ако наистина не се страхувате от мистериозен човек в черно, насочен към вашата конкретна база данни, мисля, че sha1 е достатъчно добър. Не бих въвел друга зависимост за моя проект за тази допълнителна сигурност. Въпреки това няма причина да не използвате sha1 100 пъти, което би дало подобен ефект).
