Det vanliga sättet att lagra lösenord är att använda en hash-funktion på lösenordet, men att salta det i förväg. Det är viktigt att "salta" lösenordet, för att försvara sig mot regnbågsbord attacker.
Så ditt bord borde se ut ungefär så
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |[email protected]|13%!#tQ!#3t...|
| |... |... |
När du kontrollerar om ett givet lösenord matchar en användare, bör du sammanfoga saltet till det givna lösenordet och beräkna hashfunktionen för resultatsträngen. Om hashfunktionens utdata matchar hash kolumn - det är rätt lösenord.
Det är dock viktigt att förstå att salt-hash-idén har en specifik anledning -- för att förhindra att någon med tillgång till databasen känner till någons lösenord (det anses vara svårt problem att vända en hashfunktionsutgång). Så till exempel, bankens DBA skulle inte kunna logga in på ditt bankkonto, även om han har tillgång till alla kolumner.
Du bör också överväga att använda det om du tror att dina användare kommer att använda ett känsligt lösenord (till exempel deras lösenord för deras gmail-konto) som lösenord till din webbplats.
IMHO det är inte alltid en säkerhetsfunktion som behövs. Så du bör fundera på om du vill ha det eller inte.
Se denna artikel för en bra sammanfattning av denna mekanism.
Uppdatering: Det är värt att nämna att för extra säkerhet mot riktade attacker för att vända individuella lösenords hash, bör du använd bcrypt , vilket kan vara godtyckligt svårt att beräkna. (Men om du inte är riktigt rädd för att en mystisk man i svart riktar in sig på din specifika databas, tror jag att sha1 är tillräckligt bra. Jag skulle inte införa ett annat beroende för mitt projekt för denna extra säkerhet. Som sagt, det finns ingen anledning att inte använda sha1 100 gånger, vilket skulle ge en liknande effekt).