Where to store password salt and how to get it

Question

I'm in charge of doing the authentication in our .Net MVC 4 Web Application and I have hit a bump concerning password hashing, storing and authenticating.

Plan is to currently use 2 Salts, 1 Dynamic (Per User) and 1 Static (Web App Constant) and a strong Hashing function.

Given a simple User table that contains a username and password:

• Do I store the per user salt in a column in the User Table?

My worries is that by doing so, I will have to get the user from the database in the web application memory with its username only. Is there some sort of attack where that could be problematic? Ideally I'd like to have this be a one step/one SQL Request authentication.

Am I worrying too much? Is there an alternative to a "Per User" salt where I can still do a one step authentication?

Answer 1

The salt can be stored together with the password-hash, so you can create a salt per password instead of per user. It is a common practice for password hash functions (slow key-derivation function like BCrypt or PBKDF2), to return the salt cleartext as part of the password hash, what means that you can store salt and hash together in a single database field.

To verificate an entered password, you first have to search for the password-hash (using the username or email), and then the function can extract the used salt from the stored password-hash and use it to compare the hashes. That should actually answer your question, databases usually don't have appropriate functions to hash passwords, so you cannot do the verification within an SQL-query, the verification will be done in the code.

The second salt is actually called a pepper, the best way to add this server-side secret is, to encrypt the already hashed password with this secret. In contrast to the hash, this will be a two-way encryption, what allows to exchange the key should this once be necessary.

Answer 2

You don't need an external library for doing this. The framework has its own PBKDF2 implementation built in. I prefer storing the salt in a separate field in the database but that's just a matter of taste I guess. I've written up my thoughts about password hashing here