Is using a 'salt' all that good?

Question

I don't claim to be an expert in security but it seems to me that adding a salt doesn't really make a huge difference.

For example, if the password of the user is john1970 and the salt is 123456, this means that the password is 123456john1970, while this makes things harder for an attacker (if using a dictionary attack, e.g. rainbow tables), the attacker could very possibly guess that the first part is a salt. I find using non-standard methods (like XORing with some key or applying a few simple mathematical operations to the codes of the characters) far more effective. I know most of you won't probably agree with me but but this seems to make more sense to me.

Your opinion?

Duplicate:

• Need some help understanding password salt
• Non-random salt for password hashes

Answer 1

It makes a difference for the very reason you mention: it makes things harder for an attacker using a dictionary attack.

Have a look at You Want Salt With That? for a good explanation.

Answer 2

If your salt is big enough, it's not practical to create said rainbow table.

http://en.wikipedia.org/wiki/Salt_(cryptography)

It's also about having mutiple factors being used to encrypt your passwords. While someone might steal your database, they might leave out the salt, and thus be SOL.

Answer 3

Security axiom: never ever store plain-text passwords in the database.

With this in mind, salt suddenly makes a big difference: because of this salt, the attacker’s pre-calculated hashes (the aforementioned rainbow tables) are of no value.

Answer 4

Salting does make a big difference, which hashing algorithm are you using though? Remember salt will always be added to whatever is put in the field, so even if a collision is found, if he types it into that field on the form, the salt gets added and the collision no longer matches.

Personally, I hash(hash(salt1)+hash(pass)+hash(salt2)); However salt only protects when one can get the hashes from the database. If one truly can't get to the hashes then the best one can so is type random stuff into the form.

Answer 5

I can't speak to the math behind the question, but I'll use a phyical metaphor. Just because I know that the lock on the door knob to my house can be defeated with a bump tool or a blowtorch, I still lock my door. And I'm in an apartment building with yet another door to enter the building and I lock that one, too, although you could say that door is a waste of time because many people have keys to it and the often prop it open.

Security is a set of concentric defenses, some more interesting that others. It is a judgement call about which defenses are more work than benefit, e.g. hashing + salt + ROT13 would probably add more work than benefit.

Answer 6

A salt is designed to be a defense against rainbow tables, but the beauty of it is, knowing that it is a salt in no way weakens it as a defensive measure. This is because it is not that a salt has some magical properties or anything -- it's because it's an extra piece of information added to the password the attacker enters, and is specific to the password he is attacking -- it's not something that can be reused for multiple accounts -- not even multiple accounts on the same server.

Sure, the attacker can just add the salt to his rainbow tables, but you've just made his rainbow tables have to be bigger by a factor of whatever data you use as the salt.

If you add two random bytes, you've make the attackers rainbow tables have to be 65536 times as large. That is not insignificant. Add four random bytes, and the factor is above 4 billion.

Answer 7

"1-2-3-4-5? That's the stupidest combination I've ever heard of in my life! That's the kinda thing an idiot would have on his luggage!"

Ahh spaceballs...

Anyhow, yeah, if you're using 123456 as your "salt", 007, security may not be as good as it can be. Still, you're making it harder you're eliminating dictionary attacks as a means to crack it (unless they know the salt..). Sure, it could still be brute forced, but the honest truth is that nothing is unhackable. Everything you do is all about making it harder to hack, because impossible to hack is impossible to do.

Answer 8

A salt is used in conjunction with a cryptographic hash, not merely tacked on the front of the password. You don't store the salted password or the password, but rather the hash of the salted password. The purpose of a salt is to protect users from "bad" password choices, not obscure the password. You never use just a salt.

To clarify: A salt will not protect against a dictionary attack. It can protect against a rainbow table style attack, where a large table of hashed and a corresponding input text is generated. Good passwords protect against guesses (dictionary attacks), salts help protect against someone getting a hold of your hashed passwords, by making it expensive to use precomputed tables. When I said "bad" I meant passwords that were likely to be in the extant tables.

Answer 9

The real value in a salt is not only in protecting a single record against attack, but rather making it so that if multiple users have the same password, they will appear different in their hashed form. For that to be effective, you have to use a per-record salt.

If your security encryption/hashing mechanism results in users with the same password having the same representation in your database, then you've provided the attacker with an easy method of cracking many accounts at once.

Answer 10

The purpose of the salt is not just to obfuscate the password, but to add to its length. It doesn't help much that the hacker guesses that there is a salt, if he doesn't know what it is. If the salt doubles the length of the password, that raises the number of possible words to the second power. Your XOR method doesn't do that.

Answer 11

"attacker could very possibly guess that the first part is a salt. "

Really? How? How do they know where the salt ends and the user-supplied password begins? What's the rule for parsing salt out of a password?

Are you saying it's "obvious" because the salt is numeric? Then use base64 salt. Now how "obvious" is it?

Answer 12

Salt's aren't added to make guessing a password harder on the front end, they're added to make sure that the storage of the password doesn't leak extra information.

In fact the salt is generated randomly for each password, and stored without any form of obfuscation alongside the password.

Passwords are never stored in a database, only the hash is stored (MD5, SHA1, SHA2* etc).

The MD5 of 'password' is always 286755fad04869ca523320acce0dc6a4 If you just stored the md5 in the password database, you can just look for that string and know that the password there is 'password'.

By adding a salt of '84824' the sum becomes 2ca20e59df3a62e5dc4a3a0037372124. But if you got another database (or another user uses the same password), they may have a random salt of '8999', giving: 4e7a210a07958cfe24138a644cbb7f84

The point is that if an attacker were to get a copy of the password database, the password hashes would be meaningless, you couldn't even tell if 2 or more users were using the same password.

Edit:

In comparison - the mathematical formula you apply can be reversed. If you choose a salt, then XOR the salt with the password hash, then the attacker can just undo the XOR operation and get the original hash, at which point rainbow tables are extremely useful.

If you think the mathematical formula can't be reversed, there's a chance that you're actually loosing data, and that you're mapping multiple passwords to the same final hash. This actually multiplies the chance that the attacker will find a password for the hash, since any of the appropriate passwords will work.

If you're XOR'ing and keeping the XOR value secure, then it's just an extra secret that needs to be kept somewhere divulging that secret effectively looses all your passwords (again due to rainbow tables). With salts there's no additional secrets, the operation cannot be reversed, but can be repeated, and each password needs to be attacked individually.

Edit: Of course this is now thoroughly relevant: I just logged in as you

Answer 13

What you're saying doesn't make any sense. Let's go with a simplified example to demonstrate. Assume you're using MD5, and the attacker has a table. The table includes:

john1970->D3 88 99 BC 0C B5 DC 0E D1 7F BB F7 EB F4 EA B2

If they then steal your unsalted database and see a hash D3...B2, they'll know (ignoring collisions) the password was john1970, and they can then use that password on your site and possibly others. If however, you use the salt 123456 (obviously, a random one would be better), they will see a hash:

2A CA 76 59 03 23 35 61 E0 20 49 11 8F FE F3 0E

instead. Even if they are able to compromise the salt when they get the hashes (you should try to prevent this by storing them separately), they will be left with:

md5(x+123456) = 2A...0E

and no way to easily determine x. Salts are a very powerful technique, and should be used whenever possible. On the other hand, what you call "non-standard methods" appear to be half-cocked attempts at inventing your own unproven hashing algorithm. Forget that.