3

Is using hash(salt, plaintext) equally secure as using hash(plaintext, salt), i.e. can the plain text be appended to salt in place of appending salt to the plain text.

Why or Why not?

What kind of threats it may lead to if the above approach is incorrect?

A. Sinha
  • 377
  • 1
  • 3
  • 12
  • What are you hashing and why? May I guess passwords for storage? Please [edit] the question to add that information. – Anders Apr 05 '16 at 10:56
  • 1
    For hashing passwords, either is fine. But for a "Message authentication code" it must be the secret first, or you're vulnerable to a [Length extension attack](https://en.wikipedia.org/wiki/Length_extension_attack). – paj28 Nov 03 '16 at 23:00

3 Answers3

2

If you're having to deal with this question, you are more likely than not making a big mistake: you're rolling your own password hashing code. This is bad, because:

  1. Password hashing is a complicated topic that most people get wrong;
  2. You'd be reinventing the wheel, instead of using a well-known and studied dedicated password hashing function like PBKDF2 or bcrypt.

These latter functions usually have interfaces that look like this:

  • Arguments:
    • Plaintext password
    • Salt
    • Cost factor
  • Return:
    • A password verification tag

They take the password and salt as separate arguments, so you do not need to append one to the other in any order. In fact, neither of them appends the password and the salt in either way that you suggest.

Community
  • 1
Luis Casillas
  • 10,181
  • 2
  • 27
  • 42
1

Yes, there's fundamentally no security difference to what you are doing as the result will have the same "strength" of hash.

Operationally though the two methods will return completely different hashes, which might a problem if you will be using this to authenticate to a different system. Appending the salt is the conventional way to do it, if you reverse it you will have compatibility issues.

GdD
  • 17,291
  • 2
  • 41
  • 63
1

It is, assuming that the hash is of the complete string. Look what happens when you use a password hasher that only uses the first 8 characters of its input (this is the 'traditional' (salted) Unix password hash function):

$ mkpasswd -s -S 00 <<<salt.password
002y63GMEzTFg
$ mkpasswd -s -S 00 <<<salt2.password
00OHzu67zQp/Q

Good: those two are different.

$ mkpasswd -s -S 00 <<<password.salt
00xQPHYlVDIw6
$ mkpasswd -s -S 00 <<<password.salt2
00xQPHYlVDIw6

Oops.

Note above that I'm passing a fixed salt to mkpasswd; this is so that its randomly-generated salt doesn't interfere with the principle I'm demonstrating with salt and salt2 prepended or appended to the password.

N.B. I'm not suggesting that anybody actually use the old crypt() function for hashing passwords - partly down to the truncation problem shown here, but also because the salt is much too short, the resultant hash is too short, and the algorithm is much too fast for today's hardware (a password hash function needs to be slow, to hinder cracking, but not so slow that it frustrates legitimate users).

Toby Speight
  • 1,214
  • 9
  • 17
  • 1
    But you are using `-S 00` in all of your examples, which means all of your examples are using the same salt. And that is not the scenario the question is about. Moreover the algorithm you are using has been deprecated for like two decades. That algorithm suffers from at least three serious problems: passwords are truncated, the salt is too short, and the hash is too short. Of all the algorithms supported by `crypt`, that is the only one so weak that it would keep me awake at night if my security had to rely on it. – kasperd Nov 03 '16 at 21:50
  • 1
    I used `-S 00` on all the inputs simply so that `crypt()`'s salt doesn't interfere with the one we're actually using by concatenation. I'll try to make that clearer. Agreed that it's not an algorithm you should actually *use*, for all those reasons; just demonstrating that you need to know what you're using. – Toby Speight Nov 03 '16 at 21:58
  • Is that better? – Toby Speight Nov 03 '16 at 22:04
  • Yes it is better. Though to me it feels quite unlikely anybody constructing a password hash by first concatenating password and salt would then proceed to use `crypt` as their hash function. By the way in your construction it is actually better to have the password first and the salt last. Because putting the salt first would truncate the password even more. – kasperd Nov 03 '16 at 22:23
  • If users chose passwords well, I'd agree. But we know that's not the case. I'm leaving this answer here, but it's mostly a lesson in what not to do, and a reminder that you should have a good understanding of the tools you work with. It's most definitely **not** intended as an example of good practice. – Toby Speight Nov 03 '16 at 23:00