Theoretical - Password salting with concatenation vs. salting with HMAC

Question

I was looking through different methods of salting and tried to compare which is more secure for password storage. I know HMAC wasn't meant at first for password hashing but it is widely used for that purpose. I also know the more secure method is using key stretching. I looked through CrackStation, old don't hash secrets article, question on this topic and 3 wrong ways to store passwords article. I still was not able to conclude which of the following methods is more secure than the other and why:

• sha256($pass.$salt)
• sha256($salt.$pass)
• HMAC-SHA256 (key = $pass, $salt)
• HMAC-SHA256 (key = $salt, $pass)

WARNING: None of these are secure for password storage. The question is about marginal theoretical differences between these methods of password hashing and salting.

I was considering length extension attacks which probably are not a factor here, or are they (which would make HMAC more secure)? Then also maybe would HMAC be less secure because the key is known? How would you sort those methods by security?

Answer 1

The four methods you listed are essentially equivalently secure for the purpose of hashing passwords.

The HMAC construction of H(k1 ++ H(k2 ++ m)) (where ++ is concatenation) is designed specifically to prevent attacks against MACs being used to authenticate messages as being written by someone possessing the secret key (k1, k2; where k1 = K ⊕ opad, k2 = K ⊕ ipad, where opad=0x5c5c...5c and ipad=0x3636...36). Due to common hash functions like md5, sha1, sha2 being vulnerable to length extension attacks, you can't use a construction like H(k ++ m) as a MAC, since an eavesdropper who observed a signed message m could use a length-extension attack to make a valid MAC for a message m' = m ++ tampered_msg. Similarly, the construction H(m ++ k) is also insecure if an attacker could generate a collision (find two messages H(m1) = H(m2) where m1 and m2 lined up on a block) and then if he can trick someone into creating a MAC for m1, he can use that as a valid MAC for m2.

However, being susceptible to length-extension or pre-collision attacks is not relevant for the use of storing and validating user passwords. All that is relevant is the length of the returned hash, the fact the salt is unique for every stored password in your system (so multiple passwords are not attacked in parallel, the time to calculate the hash (intrinsically slow hashes are more secure against brute force), and the strength of the password.

If I use H(random_salt ++ password) with a hash that's vulnerable to length-extension attacks, there's no equivalent vulnerability. Who cares if someone who doesn't know my password but has seen the hash could potentially calculate H(random_salt ++ password ++ tampered_pw) for whatever tampered_pw they want to add onto my password without figuring out what the password is?

That said, the HMAC construction may be a tad safer in that it calls the hash function twice, so theoretically should take double the time to brute force; though typically when you perform multiple rounds of hashing you do many thousands of rounds of hashing (that makes brute forcing many thousands of times harder) instead of just 2 rounds of hashing.

Answer 2

(None of the examples you give should be used for password hashing. They're much too fast!)

The first general principle I would mention here is that we want our cryptographic operations to be high level interfaces; there should be a common, reusable abstraction that defines:

• What preconditions the caller should fulfill before calling them;
• What arguments the operation takes;
• What values it returns, or what postconditions it fulfills when correctly called;
• What security properties the concept should offer.

In this case we're talking about password hashing. A password hashing function, in its simplest incarnation, should:

• Accept two arguments, a salt and a password;
• Return a hash code for that password/salt combination;
• Inherently consume a lot of resources so that it slows down a password-guessing attacker substantially, but not so much that an honest user

So SHA-256 fails the first and third points. It only accepts one argument, and is much too fast!

And actually, the interface described above is arguably not even the best one for password hashing. A better interface is as a pair of functions written on top of the password hash (in Python-ish pseudocode):

def generate_new_verification_code(password):
    salt = crypto_random(16)     # 16 byte random salt
    hash = password_hash(salt, password)
    verification_code = salt + hash
    return verification_code

def verify_password(putative_password, actual_verification_code):
    actual_salt = actual_verification_code[0:16]
    actual_hash = actual_verification_code[16:-1]
    putative_hash = password_hash(actual_salt, putative_password)
    return putative_hash == actual_hash

So proper abstraction says that for password verification we should be using two functions like these, written on top of a resource-intensive password_hash function, which in turn would likely be written on top of a low-level function like SHA-256.

Note that PHP's password hashing interface actually follows this latter design:

• The password_hash function is meant to be called with a password but no salt; it picks a salt randomly, and as the page says: "The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that's needed to verify the hash is included in it."
• The password_verify function is used to check whether a putative password matches the verification string.

---

Second problem: one key idea in the design of security protocols or other security constructs is that attackers will often break the rules, and cause your code to be called in unexpected manners and contexts. For example, when people write something like this:

hash($salt.$pass)
hash($pass.$salt)

...they often implicitly assume that salt will always be the same fixed length, and don't stop to consider whether some attacker might be able to:

1. Find a way to "break the rules" so that they can cause the length of salt to vary across multiple calls to the code;
2. Find some unexpected way to exploit this to their advantage.

For example, you might think it's impossible for an attacker to find a collision for passwords hashed this way, but in fact if they can control the salt and pass it's trivial to do it:

hash("0001"."Passsword1!")
hash("0001P"."asssword1!")

This might sound farfetched, and well, to tell you the truth, I can't actually think of a scenario where this might be exploitable. But we really would like our security to founded on grounds more solid than "I can't think of any way to break this." So as a general philosophy, it's safer to design things in such a way that ambiguities cannot arise. In this case, we would like the following rule to hold:

• If we hash two different passwords with two different salts, the inputs we provide to the low-level hash function should be different.

So this means that to produce the input that we feed to the underlying hash, we should prefer to combine them with an injective function—a function such that combine(salt1, password1) == combine(salt2, password2) if and only if salt1 == salt2 and password1 == password2.

hash(combine($salt, $password))

Some ways of doing this:

• Pad one of the inputs to a fixed size, and prepend it to the other. HMAC does this internally for keys.
• Hash one of the two inputs and prepend it to the other. HMAC does this for keys that are longer than the underlying hash function's block size.
• Put an unambiguous delimiter between the inputs (possibly requires you to escape occurences of the delimiter in the input values).

---

Dedicated password hashing functions like PBKDF2, bcrypt, scrypt and Argon2 adhere to most of these ideas.

Answer 3

HMAC, by itself, is not an appropriate password hash. You are working at way too low a level for your cryptographic expertise. Constructs designed specifically for foolproof verification of passwords already exist; use them! Choose one of bcrypt, scrypt, or Argon2.

Answer 4

Based on additional research and conversation on reddit, I guess the order would be:

(more secure)

1. HMAC-SHA256 (key = $salt, $pass) - best because it doesn't have drawbacks of limiting password length, it also seems favorable because key is more random which might make hash even more random and you don't have to sanitize password in some cases (thanks to @Nat)
2. HMAC-SHA256 (key = $pass, $salt) - possibly limited password length based on sha256-hmac implementation, more secure because of a bit higher work factor
3. sha256($pass.$salt) - based on some specifics of SHA implementation it is more secure to append salt
4. sha256($salt.$pass) - prepending salt not as secure

(less secure)

Disclaimer: This difference is more of a theoretical nature and in practice you should not use any of these methods but use any of these stated in Stephen's answer.