14

Possible Duplicate:
Why is using salt more secure?
Why would salt not have prevented LinkedIn passwords from getting cracked?

Recently I decided that I wanted to learn more about web security, and I've come to a point where I think I understand pretty well how to securely store passwords. I've been using random salts along with hashing for password storage, and I am pretty confident in my solution. However, I came across an article that surprised me a lot. Here is a quote from it :

Salts Will Not Help You

It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database.

Well now I am confused...

Is adding salt to passwords still relevant?

Community
  • 1
marco-fiset
  • 243
  • 1
  • 6
  • Interesting reading: http://blogs.msdn.com/b/ericlippert/archive/2005/01/28/362587.aspx – StuperUser Jul 20 '12 at 12:49
  • Why would such points prevent salts from being relevant? The points in that article have applied to salts all along. – Brian Jul 20 '12 at 12:54
  • @StuperUser I just read the first part and it looks very promising! Thanks for the link. – marco-fiset Jul 20 '12 at 12:54
  • 12
    What this guy is saying, is that wearing your seatbelt doesn't protect you against catching a cold. Certainly true, but not very useful information, and definitely not something that you should act on. – Jörg W Mittag Jul 20 '12 at 13:04
  • @JörgWMittag Ok so if I understand correctly, salts are still useful, but do not protect you against every type of attack? – marco-fiset Jul 20 '12 at 13:08
  • If this were posted on IT Security then I can see it being closed as duplicate, however I still feel that it is relevant to implementing password related security so it may be on topic here. It already has 3 close votes, if it gets one more then I will close it. –  Jul 20 '12 at 14:29
  • 12
    http://cooking.stackexchange.com/ is a better place to ask such questions – SplashHit Jul 20 '12 at 15:01
  • @maple_shaft The problem with security questions on this site is edmonstrated here: the [top-voted and accepted answer](http://programmers.stackexchange.com/a/157575) completely misses the point. – Gilles 'SO- stop being evil' Jul 20 '12 at 18:14
  • Also of interest: [Why would salt not have prevented LinkedIn passwords from getting cracked?](http://security.stackexchange.com/q/15910) – Gilles 'SO- stop being evil' Jul 21 '12 at 11:07

7 Answers7

33

Yes and no.

Salt protects you against someone obtaining your database and deducing the actual passwords even though they are hashed. (If someone steals your entire database, it is likely that they have also obtained the user data that the passwords were supposed to protect in the first place, but let's assume that passwords are even more valuable than use data, because many people use their passwords on multiple sites, which would then also be compromised.) therefore, both hashing and salting is standard practice to optimally protect your users.

However, salt doesn't protect you from people choosing "password123" as a password, and an attacker simply trying out common passwords. Nothing can protect you from that - if the user can enter their lame password and obtain access, so can an attacker (the system doesn't know who is at the other end of the line, which is the entire point of passwords to begin with).

For good security, both the provider and the user have to act in a minimally competent manner - one of the two isn't enough.

Kilian Foth
  • 907
  • 2
  • 6
  • 8
  • 6
    +1 for "If someone steals your entire database, it is likely that they have also obtained the user data that the passwords were supposed to protect in the first place", I never thought of it this way !! – marco-fiset Jul 20 '12 at 12:57
  • 12
    @marco-fiset: Unless you're a bank, it's probably not the user data they're after; it's the passwords themselves. Hackers go after password lists because they know that a lot of people use the same password for multiple sites. So if they can steal your Twitter password, they just might be able to break into your PayPal account too. – Mason Wheeler Jul 20 '12 at 16:19
  • 5
    Salts don't *"prevent someone from deducing the actual password"*, they just make it harder, which is always a good thing. Another common practice *(though not as common as it should be)* for the same reason is using a very **SLOW** hashing algorithm, like [bcrypt](http://en.wikipedia.org/wiki/Bcrypt). Using bcrypt with a per-user salt and a site-wide salt *(so that someone who gets your database cannot crack **any** of the passwords unless they also have your source-code, which is much less common)* is about the best you can do when it comes to password-storage. – BlueRaja - Danny Pflughoeft Jul 20 '12 at 16:55
  • 5
    A salt alone doesn't prevent anyone from getting the password from the hash, it only prevents the use of rainbow tables. If you use a fast hash like md5 or even SHA-512 an attacker can still brute-force even reasonably strong passwords using GPUs. You have to use a slow hash designed for this purpose like PBKDF2, bcrypt or scrypt. – Mad Scientist Jul 20 '12 at 16:59
  • I am already using bcrypt as it seems to be the most accepted algorithm for password hashing. – marco-fiset Jul 20 '12 at 18:04
  • 1
    Keep in mind that you should use a non-public value for a salt, as I describe [here](http://security.stackexchange.com/questions/17421/how-to-store-salt/17435#17435). The salt should not be any more public than the password hash. If the salt is available, you're vulnerable to attacks using single-salt rainbow tables which give you no time to respond to a breach. – Polynomial Jul 20 '12 at 23:41
28

Salt aren't there to prevent those. Salts are there to prevent attacks using rainbow tables, which are basically lists of hashes and their passwords. This is when an attack already has your password hash.

Pieter B
  • 665
  • 5
  • 8
20

In addition to rainbow tables, salts prevent someone with access to your database from knowing if any given pair of users share the same password.

Brian
  • 962
  • 5
  • 17
18

Salts don't help prevent someone from cracking a particular password. They help prevent someone from cracking many passwords at once using a rainbow table.

Say you have the following users on your site (the password wouldn't actually be stored in the database, just the hashed version).

USER         PASSWORD    HASHED PASSWORD   
========================================  
hamfist      god         de898928393a893
bttltoad     god         de898928393a893
woob         god         de898928393a893
marco-fiset  mypass1     1238ffff2342399
dean         password2   a44ca77446ff449

If someone were to pre-compute the hashes for a ton of passwords ahead of time and store this in memory (a rainbow table) then it would be trivial for them to check if de898928393a893 existed in the password list. They would then know that all of these users accounts could be accessed with the password, god. In very short order, they would have access to the accounts of everyone with a simple password that exists in their rainbow table (and anywhere else on the web that person uses the same email/password combo).

Now if you add a random salt, everyone with the same password will end up with different hashes:

USER         PASSWORD    SALT   HASHED PASSWORD   
===============================================  
hamfist      god         ae#o   abf4388ff343401
bttltoad     god         cdo@   29292d919100001
woob         god         !doe   3902dda99210099
marco-fiset  mypass1     12uo   aaffff121bcce13
dean         password2   TEe9   b44ca7743324234

Now a rainbow table doesn't really help. Instead of just needing the hash for god, for instance, you'd need to pre-compute the hash for god + <all_potential_salts>. Kind of limits what you can store in memory.

However, if someone is out to get hamfist specifically, they have the salt since it's stored in the database, so this isn't going to slow down a cracking attempt at all.

Dean
  • 528
  • 1
  • 4
  • 8
5

There's another section of the article which answers your question:

You said salts aren’t helpful, but what about rainbow tables? Why would you suggest people not use salts?

As the Provos & Mazières paper describes, bcrypt has salts built-in to prevent rainbow table attacks. So I’m not saying salts are without purpose, I’m saying that they don’t prevent dictionary or brute force attacks (which they don’t).[emphasis added]

Brendan Long
  • 2,898
  • 1
  • 19
  • 27
3

As the others said, they just protect you from rainbow tables and maybe differentiating same password-hashes among different sites. You should not make any efforts on making salt secret(many mistakenly advocate to put them on a different seerver etc), keeping salt alongside password hashes would be alright. All your efforts should be concentrated on making secure the location of the password hashes.

Dim
  • 141
  • 2
1

If I understood correctly, the quote say "It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database", and "salt from you database" is the main part here.

If you store the salt on the database, and an attacker has access to that database table where he finds the hash and the salt, it can brute-force attack those hashes using the salt, so using or not using a salt is the same (except for the attacker slowdown due to increased hashing work, which is a factor, but not such an important one).

Seen this way, it does make sense, if the attacker has "salts from you database".

  • +1 but another recommended defense against brute force is to iterate through the hash many times eg. 1000 so the attacker has to also try multiple iterations for each attempt –  Jul 20 '12 at 14:05
  • Hi James, yes, but when you receive a password you have to check it against your database records, so you are saving in the db all the informations needed to get to that hash, so the attacker will have those same informations as long has he manages to get that entire table. You can make it longer for he (and for you) to get there, but informations are still there. Even public/private key pairs are still only creating a big computational requirement on those not having the private key, but at least in that case it is highly asymmetric, you get there in one second, he in 2 billion years. –  Jul 20 '12 at 14:11
  • @james Iterating through the hash function a number of times isn't as effective as it sounds. You still end up with a hash that is one layer away from *some* password. Sure, it's not close to the original password, but it will still match something. This issue is greatly mitigated by using a strong hashing algorithm to begin with, and by using a slow one as well. – DavidO Jul 20 '12 at 17:06