0

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:

Community
  • 1
  • 1
Waleed Eissa
  • 10,283
  • 16
  • 60
  • 82
  • 4
    Applying xor is not "non-standard" -- it's pretty typical -- and doesn't work well. – S.Lott Apr 28 '09 at 12:38
  • 11
    Salt is great. Not only is it a useful seasoning in its own right, but it amplifies the other flavors in a dish. Sure, "too much of a good thing" and all that, but... what? Oh, /that/ salt... – Pesto Apr 28 '09 at 12:41
  • @S.Lott, I'm not talking about XORing the password and saving it in the database, I'm talking about XORing before hashing (encrypting the password before hashing should be even much more effective) – Waleed Eissa Apr 28 '09 at 13:01
  • 2
    Xoring before hashing is irrelevant for the same reason that simple xor'ing is irrelevant. It's easy to reverse. 256 tries and you've figured it out. – S.Lott Apr 28 '09 at 13:06
  • All simple mathematical mappings are easy to break. What you're doing is about as silly and less secure than doing hash(hash(x)). – dbkk Apr 28 '09 at 13:09
  • @dbkk hash(hash(x)) is not silly, it increases the amount of processing power needed to do a brute-force dictionary attack. – Richard Gadsden Jul 07 '11 at 16:25

13 Answers13

21

Salts 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 wouldn't even be able to 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 losing 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, and divulging that secret effectively loses all your passwords (again due to rainbow tables). With salts there are 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

Cœur
  • 37,241
  • 25
  • 195
  • 267
Jim T
  • 12,336
  • 5
  • 29
  • 43
  • 1
    It's not meaningless, it would now take a hell of a lot longer as simple rainbow tables now need to be made for each salt, exponentially growing them in size. Generating such tables suddenly becomes infeasible for MD5 (although I wouldn't recommend anything but SHA-256 noW). – ewanm89 Apr 28 '09 at 12:50
  • 7
    Upvote for a key observation that salt should be different for each user. That is non-obvious, and important. – dbkk Apr 28 '09 at 12:59
  • See also: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190 – Jacco Dec 26 '09 at 13:11
  • 3
    "Passwords are never stored in a database, only the hash is stored (MD5, SHA1, SHA2* etc)." - Probably should say "Passwords SHOULDN'T be stored in a database..." Unfortunately, I have seen cases where they are. – JasCav Feb 09 '10 at 23:36
  • 3
    The md5 of "password" is actually 5f4dcc3b5aa765d61d8327deb882cf99, not 286755fad04869ca523320acce0dc6a4. (286755fad04869ca523320acce0dc6a4 is the md5 of "password\n". :P) – Benji XVI Nov 09 '14 at 12:05
16

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.

Anton Gogolev
  • 113,561
  • 39
  • 200
  • 288
  • 1
    Did you read the original question? The poster is aware the use case. But asking if using XOR or a mathematical formula better than prepading or post-pading the password with a salt string. – CDR Apr 28 '09 at 13:02
10

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.

Logan Capaldo
  • 39,555
  • 5
  • 63
  • 78
  • Salt does not protect against bad password choices, there is no defense to that other than password strength checking on entry. (I just hate sites that moan about characters like a . in my passwords, yes I'm talking about my damn bank...) – ewanm89 Apr 28 '09 at 12:37
  • I quoted "bad" for a reason, ah well. – Logan Capaldo Apr 28 '09 at 12:43
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.

Jonathan Rupp
  • 15,522
  • 5
  • 45
  • 61
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.

OtherDevOpsGene
  • 7,302
  • 2
  • 31
  • 46
  • If you link had another page, this would be it: http://srp.stanford.edu/ Maybe not useful in all cases but interesting reading. – Eyal May 06 '09 at 14:56
5

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.

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
4

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.

Mihai Limbășan
  • 64,368
  • 4
  • 48
  • 59
cgp
  • 41,026
  • 12
  • 101
  • 131
2

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.

ewanm89
  • 919
  • 5
  • 22
  • Good explanation, but no reason to do so many hashes. hash(salt + pass) would suffice if you vary and store your salt (it should be per-user, not one for the whole system). Unless you're a security expert, it's dangerous to roll your own methods. – dbkk Apr 28 '09 at 13:06
  • The reason I do it that way is that way the weaknesses due to hash length are ironed out, it makes sure the padding is enough. – ewanm89 Apr 28 '09 at 13:19
  • the + are concatenation, not bit addition or any such thing. – ewanm89 Apr 28 '09 at 13:26
  • 2
    If you care about hash length, using 2 concatenated hashes of length x is much less secure than using one hash of length 2x. If your source code gets compromised (it can happen!), and they know what you're doing hash64(a) + hash64(b), rainbow tables make it *much* easier to break this than hash128(a+b). – dbkk Apr 29 '09 at 04:42
  • 1
    You should design your security with the assumption that hackers can get to *everything* you store. It's good to use standard practices -- very few of us (myself included) know enough about security to come up with a solid improvement. Seems easy, but the security holes will be subtle (like the one above). Unlike most bugs, this won't fly in your face until it's way too late, and in the meantime you'll have a false sense of security. – dbkk Apr 29 '09 at 04:49
  • check mine and it's not even two hashes the fact it's three makes rainbow tables suddenly impossible to break. And you might want to check my bio ;). – ewanm89 Apr 29 '09 at 08:38
  • and that method isn't self rolled, it's a while since I've seen the paper about it. – ewanm89 Apr 29 '09 at 08:44
2

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.

Jeromy Irvine
  • 11,614
  • 3
  • 39
  • 52
1

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

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • Let's say we use some random characters, e.g. j23$kM2, now add this to a simple password (let's use the password in the question, john1970), now we have j23$kM2 + john1970 = j23$kM2john1970 .. isn't this obvious enough? encrypting the password before hashing won't make the rainbow dictionary attack harder, it will make it useless. – Waleed Eissa Apr 28 '09 at 12:54
  • The idea of a salt is not to be secret, if one has the password hashes, then they'll have the salts too. Hell in most cases they are stored in the same damn table. No, salt means I can't use premade hash tables (rainbow tables), and I can't do an MD5 collision attack. Instead I need to find a collision that works once it's been salted, this is now computationally infeasible even with weaknesses such as those in MD5. – ewanm89 Apr 28 '09 at 13:02
0

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.

MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
  • I'm not saying that salting is not useful, but if we're talking about absolute security, then all I'm saying is that encrypting the password or even XORing before hashing is way more effective .. – Waleed Eissa Apr 28 '09 at 12:37
  • 1
    Encryption is not more effective as it is reversable... If one is likely to get to the database they also likely have enough data to be able get the encryption keys out of the database. XOR: This is built into the hashing functions, xor is one of the many operations done to create a secure hash anyway... applying lots more of it doesn't help, actually it can make things worse. This is why there are big competitions to find secure hash funxtions and the such. – ewanm89 Apr 28 '09 at 12:45
  • You're assuming that the attacker knows the password was encrypted before hashed, besides if the attacker can get the encryption key then they definitely can get the salt – Waleed Eissa Apr 28 '09 at 13:07
  • Encryption also missing the point of adding bits to make sure that the string to hash is even long enough to do so securely. – ewanm89 Apr 28 '09 at 13:25
  • hmm .. what about using Asymmetric encryption with one key (generate only one random key, or if you have both keys throw away one of them), how reversible is this? To be honest though, I believe it's best to use both, i.e. add the salt (a long enough one) to the password then encrypt the result with an Asymmetric encryptor as mentioned above, then hashing the result – Waleed Eissa Apr 28 '09 at 14:31
  • is far less efficient than hash algorithms anyway, and isn't any more secure. – ewanm89 Apr 29 '09 at 08:39
0

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

Pete H.
  • 1,427
  • 1
  • 12
  • 16
  • 4
    A salt should *not* be constant. It should be different for each password. A constant salt would allow a dictionary attack against your account list (though the dictionary would be custom to your account list). – Jonathan Rupp Apr 28 '09 at 12:35
  • 2
    Random, or just some other user data in the database, say email address or some such. Something not entered in the login form and unique to each user. – ewanm89 Apr 28 '09 at 12:39
  • Thanks for clarifying, I wasn't trying to delve too deep into it, just stating where the misconceptions were... – Pete H. Apr 28 '09 at 12:42
0

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.

TrayMan
  • 7,180
  • 3
  • 24
  • 33
  • With XORing the attacker will get a completely different password .. while salting makes the attack far more harder, XORing will make it almost impossible (unless they know it was XORed) – Waleed Eissa Apr 28 '09 at 12:48
  • 1
    Accept what to XOR it against must be stored somewhere... This no longer makes it any more secure. (in fact it's false sense of security) – ewanm89 Apr 28 '09 at 12:52
  • The same thing applies to the salt – Waleed Eissa Apr 28 '09 at 13:11
  • Other than the fact the first thing the hash function does is end up undoing half you XORs... Leave the function to do that bit. The salt is not there to be secret in anyway, but to add padding, make rainbow tables useless and to remove the ability to perform collision attacks. – ewanm89 Apr 28 '09 at 13:23
  • xOR is even counterproductive - existing rainbow table will have the same-length xor'd password -> XOr w/ known salt = password – James Jan 06 '10 at 08:21
  • 1
    "(unless they know it was XORed)" - security through obscurity != security. – James Jan 06 '10 at 08:27