Store, retrieve and validate password (SecureString) in SQL Server

John the Ripper picture John the Ripper · Sep 5, 2011 · Viewed 7.7k times · Source

I have a login window that gets the username and password from the user and I would like to know the best way to handle the password. The username is just a regular textbox, but the password is a PasswordBox. I pass the username directly to the ViewModel, but only set a SecureString property on the ViewModel once the Login button is clicked using Code-Behind. After the Password SecureString is set I want to Validate.

I'm writing the LoginBox now, but I don't have the Model fully worked out yet. How should I store the password in SQL Server? Do I just write the contents of the SecureString to SQL and then try to compare it when the user tries to login?

Answer

Yahia picture Yahia · Sep 5, 2011

You should NEVER store a password - not even encrypted...

Just store a hash of the password (which prevents the pasword from being ever retrieved as long as the hashing is implemented in a secure manner) and for validation you hash the user supplied password the same way and compare the results...

There are standards to do so:

The above standard makes it hard to use rainbow tables etc. because it makes the calculation very expensive since it uses several rounds in addition to a salt... thus hashing is for example 1000 times slower (with 1000 rounds) but this is exactly what you want - the attacker will need to do the same calculation and thus will need 1000 times the precessing power or time to achieve the goal by brute force...

You can store the result either as VARBINARY directly or as VARCHAR after Base64- or HEX-encoding the bytes... you will need to store the salt along with it (which is no security risk as long as every password gets its own distinct cryptographically secure generated random salt).