How secure is storing salts along with hashed password

13
votes

If you had looked at table schema of asp.net membership system they store the hash of raw password along with salt used to produce it. see the schema below,

dbo.aspnet_Membership

ApplicationId
UserId
Password
PasswordFormat
PasswordSalt
MobilePIN
Email
. . .

  • If a attacker gets hold of the datbase isn't it easier for him to crack open the raw password from the salt and hashed password?

  • After looking into some records it seems a new salt is generated for each password. What is significance of this?

  • Would you recommend such a approach, or hard-code constant salt in the code

Related

Are salts useless for security if the attacker knows them?

3
c#encryptionhashcryptographypasswords
Small note, you have to store the salt somewhere. – user7116
@sixlettervariables yeah the framework stores it in next column to password column, look at the schema in the question. – Deeptechtons
I was pointing out why the two are found together. – user7116
@sixlettervariables LOL my question was also regarding that – Deeptechtons

3 Answers

13
votes

For the specifics of ASP.NET password/hash/salt storage see for example http://msdn.microsoft.com/en-us/library/aa478949.aspx

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.

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

NOTE:

Using such a mechanism is these days mandatrory since "CPU time" (usable for attacks like rainbow tables/brute force etc.) is getting more and more widely available (see for example the fact that Amazon's Cloud service is among the top 50 of fastest supercomuters worldwide and can be used by anyone for a comparatively small amount)!

8
votes

The goal of salts is to slow down, not prevent outright, the possibility of hacking your database. But it slows the hacker down considerably! From a mere few seconds to, depending on the algorithm, length of salt, and other facters, hours, months, or universe lifespans.

That said, you must store salts with salted passwords, otherwise it is impossible to verify the passwoards after the fact.

There are a few things you can do to make the whole thing more secure:

  1. Never use the same salt. It should be different for each password
  2. Use a long salt. An GUID is generally a popular option. I usually generate them by getting the MD5 hash for a random number
  3. If you want, you can run your hashing algorithm more than once. This lengthens the time it takes to brute force a password.
0
votes

I wouldn't use MD5 SHA1 is much safer. But to be honest, if you know anything about security and cryptography, these are one way functions. So mostely no one will lose so much of his time attacking something that won't give him some money :D. If you think that you aren't safe with this use RSA, but use very-verya-very long number as key.