Hashing and salting a password field

I have been tossing around the question of how to store the passwords in my DB for some time now. This is my first time at making a secure application with a web login, so i wanted to set up some good practices.

First, i read up on hashing and salting. It seems that the idea is...

1. Get hashing algorithm
2. Get password from user
3. Add 'salt' to plain text password from user
4. hash the entire password (including salt)
5. Store the salt in the db so that you can retrieve it later (for verification of PSWD)

And that got me thinking... If a hacker knows your salt (beca开发者_StackOverflowuse it is stored in the DB somewhere, maybe a column called this_is_not_the_salt_ur_looking_for or something equally ambiguous) they can re-generate the password dictionary and gain access.

Then i had an idea. What if you stored your salt inside the hashed password field. So follow steps 1-4 (randomly generating the salt), then in step 5, insert the salt in the password somewhere known by the password interpreting class or service:

xxxxxsaltvaluexxxxxxxxxxxxxxxx

where x is the hashed string values. Can anyone see any issues with this? is it just completely unnecessary?

Answer:

There is no reason why this couldnt be done. As Yahia states, other methods of securing a password include double (or n) hashing. On another note, BCrypt looks like a good method of stopping brute force attacks almost entirely, but I couldnt find a trusted library for C#

Thanks!

TTD

From a security standpoint that is not necessary as long you only store the hashed password (NEVER store the cleartext password!) plus the salt... an attacker is "allowed" to know the salt - your security must be designed in a way that even with the knowledge of the salt it is still secure.

What does the salt do ?

Salt aids in defending against brute-force attacks using pre-computed "rainbow-tables".
Salt makes brute-force much more expensive (in time/memory terms) for the attacker.
Calculating such a table is expensive and usually only done when it can be used for more than one attack/password.
IF you use the same salt for all password an attacker could pre-compute such a table and then brute-force your passwords into cleartext...
As long as you generate a new (best cryptogrpahically strong) random salt for every password you want to store the hash of there is no problem.

As for your idea in "disguising" the salt
That is more of "security by obscurity" which should be avoided.
Although in this case I neither see any positive nor negative effect.

IF you want to strengthen the security further
You could calculate the hash several times over (hash the hash etc.) - this doesn't cost you much but it makes a brute-force attack / calculating "rainbow-tables" even more expensive... please don't invent yourself - there are proven standard methods to do so, see for example http://en.wikipedia.org/wiki/PBKDF2 and http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

You're about to fall into a rabbit hole. Use bcrypt.

Just hash the Password and save the Hash value in your Database, once the User logs in again you calculate the Hash value of the passwort he enteres and compare it with the one saved in your Database, you dont need to know the password. a Hacker wouldnt be able to get the password if he gets the Hashvalue.

If you Use Salting you will increase security by saving the Salt and the Hash value it belongs to, the end value is calculated using the generated salt combined with the password from which the hash value was calculated, the password is not saved in your database but only the calculated Hash value, it means an evtl. Hacker cant do anything having only the Hash value and Salt.

Read this