12

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?

Community
  • 1
  • 1
Deeptechtons
  • 10,655
  • 24
  • 92
  • 175

3 Answers3

14

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)!

Yahia
  • 68,257
  • 8
  • 107
  • 138
  • Wow. I came up with pretty much the same answer you did, although yours is written much better. :) – Jordan Reiter Nov 15 '11 at 07:17
  • @Yahia so it does seem to me that new salt is generated by the framework for each password save. Another question i wanted to point is `How would i authenticate a valid user?` if a new salt is generated each time. – Deeptechtons Nov 15 '11 at 07:21
  • @Deeptechtons since you store the salt along with the hash you just lookup the salt for that user recompute the hash (using entered pw and salt from db) and compare the result to the hash stored in the DB... if equal all is fine, if not the entered pw is plain wrong... you could even lock the account after a certain amount of wrong pw entries to make this a bit more secure. – Yahia Nov 15 '11 at 07:23
  • @Yahia Sorry to bother you but i am failing to realize the derived bytes hashing algorithm, could you take time to put a sample for me. The sample on msdn confused me on why they used encryption, is it really necessary how to get salt and hashed password – Deeptechtons Nov 15 '11 at 09:12
  • 1
    @Deeptechtons to get a Base64-encoded string of the hash for your pw using your salt you can use this code `Convert.ToBase64String((new Rfc2898DeriveBytes(YourPWD, YourSALT)).GetBytes(20))`. – Yahia Nov 15 '11 at 09:25
  • thanks for the help , i understood what the mistake was from that simple line of code – Deeptechtons Nov 15 '11 at 09:37
  • 1
    Good answer, but I wouldn't phrase that last part as optional - every site should be using proper hash strengthening like PBKDF2 or SCrypt. – Nick Johnson Nov 15 '11 at 23:22
  • A salt alone does not slow down brute-forcing a password hash, it only prevents rainbow tables and similar things. You need a slow hash function for this. PBKDF, bcrypt or scrypt are the things to use here. – Paŭlo Ebermann Nov 16 '11 at 13:07
  • @PaŭloEbermann that depends on the scenario... Rainbowtables are used to accelerate the hack... if you have the same salt for all password then they can be valuable... if not the only option is brute-force thus slower... when looking at exactly one password hash/salt then you are right... thus the inclusion of PBKDF in my answer. – Yahia Nov 16 '11 at 13:22
8

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.
Jordan Reiter
  • 19,797
  • 11
  • 92
  • 156
  • +1 nice answer :-) only point I am not comfortable with is "implementing yourself", esp. in security use proven methods instead of trying to "invent" (this can and often does lead to not strenghtening, sometimes even weakening security) – Yahia Nov 15 '11 at 07:26
  • @Jordan `you must store salts with salted passwords, otherwise it is impossible to verify the passwoards after the fact.` did answer one of my doubts – Deeptechtons Nov 15 '11 at 07:29
0

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.

Nermin Huskić
  • 3
  • 3