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

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 2

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 3

"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 4

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 5

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 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.