2

This is a question about salting phrases that need to be hashed.

I was wondering if it more secure to prefix the salt to a phrase or postfix it? salt + phrase or phrase + salt

My question comes from this comment on this post on MD5s. I am not sure I understand the reasoning behind the author's comment.

Raj Rao
  • 8,255
  • 11
  • 63
  • 77
  • 4
    The real question is why are you using MD5? – BobbyShaftoe May 13 '09 at 03:39
  • 2
    asked and answered: http://stackoverflow.com/questions/674904/salting-your-password-best-practices – Randolpho May 13 '09 at 03:58
  • I still havent gotten a reasonable explanation regarding the comment by Dru Nelson on skrenta's blog post about MD5. But the consensus seems to be (only by majority), that the placement of the salt makes no difference. I just dont want to be overlooking something (that is if Dru Nelson is indeed on to something in his comment) – Raj Rao May 28 '09 at 19:23
  • Dru Nelson's comment on Skrenta's blog post is reproduced here for your reading convenience: however i will add.. your handwaving example of using hash = md5(s . 'xyzzy') to overcome a malicious party who wants to cause collisions is not going to work. appending the same thing to two messages that hash the same will yield two new messages that hash the same. in fact, this is what makes it so easy to create arbitrary messages which hash to the same thing (it does not require a "sophisticated attacker" at all) – Raj Rao May 28 '09 at 19:23

5 Answers5

4

Whether the salt is appended to the front or the back makes no difference.

The following factors will affect security though

  1. Is your salt private (if so how private is it?). The more private the better. This means that if you can avoid storing your salt in your db you can make your system safe against brute force attacks even if your db is compromised.
  2. Is your salt random per value salted? This helps defend against rainbow table attacks if say your db is compromised and your salt is stored in the db. Note: if passwords being stored are long enough they can be immune to brute force attacks.
  3. Is your salt long enough? The longer your salt the more secure you are.
Sam Saffron
  • 121,058
  • 74
  • 309
  • 495
  • 4
    It wasn't me (I upvoted) but I'd guess because of your first bullet. A private salt doesn't really add security. Even if a cracker gains access to the hash and salt, as long as the salt is long enough and random per password, a rainbow table is computationally prohibitive. – Randolpho May 13 '09 at 04:02
  • Sure, but brute forcing short password is still very much possible if the salt is public – Sam Saffron May 13 '09 at 04:03
  • 2
    @SamSaffron : This is a necro-reply, but prefixing the salt is a bad idea because it makes it easier to brute-force the password. If you hash the salt/password bytes of `sssspppp`, the attacker can compute a hash-state for the known `ssss` portion and then use it as a "base camp" for repeatedly attacking the unknown `pppp` portion. – Darien Jun 29 '15 at 23:51
  • **If a salt is more private than the hash, it isn't a salt at all.** Something that's private is a key (so perhaps you're using a keyed hash function), not a salt. – Charles Duffy Sep 26 '17 at 16:43
1

It doesn't matter when you digest the salt: prefix, postfix, infix all produce different hashes, but achieve the same purpose of defeating rainbow tables or other pre-hashed dictionary attacks.

I think that the comment has to do specifically with a vulnerability in MD5, not hashing in general. I don't understand the details, but it has to do with finding two prefixes that produce the same hash.

erickson
  • 249,448
  • 50
  • 371
  • 469
  • Thats not the way collision attacks work. you need to know the full message being hashed to produce collisions. you can not produce collisions from a partial message – Sam Saffron May 13 '09 at 03:53
  • You find two different messages that produce a hash collision. Then you append the same suffix to each of these prefixes and you get another collision. I think the cited comment was trying to explain a password crack that used this vulnerability, but I don't understand exactly how he thought it works. – erickson May 13 '09 at 06:09
  • Really? The output of MD5 is simply its last intermediate hash value. If you have two different prefixes that collide it means the intermediate hash value is the same—and that value is the entire state of the hash. If two MD5 hashes in an identical state digest the same data, what would you expect the results to be? See http://www.win.tue.nl/hashclash/rogue-ca/ – erickson May 13 '09 at 14:42
  • comment stricken, true, if you prefix collides and you append the same suffix it will result in a collision as well. I have no idea how this could be exploited though in a password storage scenario – Sam Saffron May 13 '09 at 23:30
1

When someone has a question about the use of salts I fear it is because they are busy (re)inventing things they really shouldn't be in the first place. Based on the question my recommendation is to use an HMAC.

Einstein
  • 4,290
  • 1
  • 21
  • 19
  • 1
    if you use HMAC you still need a private key which has to be stored somewhere ... same factors that affect the salt based security affect the choice of key for your hmac algorithm – Sam Saffron May 13 '09 at 03:59
  • The question was about the location of salts - NOT key management. HMAC use solves the location issue. – Einstein May 13 '09 at 04:33
0

unlike what others said, it does matter! and as @einstein if you care use HMAC.

why prefix is bad, because one can calculate the intermediate state of the checksum up to the given fixed salt prefix. then start calculating the rest in parallel. In summary phrase+salt is more secure than salt+phrase, but HMAC(salt, phrase) is even better.

related reading

Muayyad Alsadi
  • 1,288
  • 13
  • 20
-2

Technically it doesn't matter, so long as the salt is unique and not easily guessable. Just don't make the mistake of storing the salt, like I did.

The purpose of "salting" a string is to scramble it in a way a bit more personal and unique than an MD5 hash will do. There's no right or wrong way to do it, just so long as you're the only one that knows how it works. It will achieve the result either way, which is to make the MD5 hashes generated not correspond with a rainbow table for easy cracking of passwords.

Nicholas Flynt
  • 6,608
  • 12
  • 47
  • 69
  • Well, technically doing it a particular way can prevent against that mindset if a cracker assumes a common way. In other words, prefix and postfix are more/less vulnerable against certain threats, if my research is valid. So the downvote may be appropriate if you're security paranoid, I don't pretend to be the know-all expert on such things. ^_^ – Nicholas Flynt May 13 '09 at 05:58
  • 2
    -1 Salt is stored openly with the encrypted password to defend against amortizing attacks over many encrypted passwords. It shouldn't be confused with a private key. – starblue May 13 '09 at 16:30
  • Wha? I was always under the impression that a salt was prefixed/postfixed to a password *before* hashing. Clearly I was mistaken then, I get to go do more research. Yay! – Nicholas Flynt May 16 '09 at 06:56
  • @SamSaffron, the reason to downvote it is that it's wrong. "Salt" is a technical term with a specific meaning, and having the same level of security as the hash itself is part of that meaning. If something is private, it's not salt, it's a key (and maybe you're using a HMAC-keyed hash instead of a salted hash). – Charles Duffy Sep 26 '17 at 16:38