CODEWITHSUNDEEP
asp.netsql-servert-sqlpasswords
GoldBishop
GoldBishop

Reputation: 2861

Where should I create a password salt

I have been searching for a preferred location to create a password salt.

For me it makes sense to create the password salt the database level and do the hashing of the entered password + salt at the database level.

But as I am an ultra-noob on login security, I wanted to know which location is best for creating the salt itself.

From what I have read, I have created a stored procedure that takes a userlogin and password and compares the stored salt concatenation to validate if the password entered is correct.

What I need to know now, is where should the password salt be created on a new user account?

My intent is to have a non-refundable password if the user forgets. If they forget it gives them a temp and then requires a change afterwards. As well, if the password changes, I also want to change the salt accordingly.

I have no illusion of total security, only want to mitigate the opportunity.

Upvotes: 3

Views: 192

Answers (1)

martinstoeckli
martinstoeckli

Reputation: 24141

The place to generate the salt and to hash the password, should be in the code, not in the database.

To hash passwords you need a slow key-derivation function like BCrypt or PBKDF2, but most databases have no implementations of such functions. These functions have a cost factor, which controls the necessary time to calculate the hash-value (the longer the more secure against brute-forcing). The salt as well as the cost factor is usually stored in the same string as the password-hash, so you need only a single field to store the hash.

To verify the password, you first have to search with the username for the password-hash, then the function can extract the used salt and the cost factor, and finally the entered password can be hashed with the same parameters for comparison.

There is another reason to do it in the code, password-systems have to switch to stronger algorithms or have to increase the cost factor in future, then it is much easier to handle backwards compatibility in code, as with SQL statements.

Upvotes: 2

Related Questions