HMACs that have the same key and message

Question

im using HMACSHA256 to generate the hash of password and store it. the objective here is to just authenticate users, i.e - save their hashed passwords, and validate users whenever needed using the hashed passwords

// salt is a guid we store seperately, its the id of the user
byte[] GetHash(byte[] password, byte[] salt) 
{
    byte[] saltAndPassword = salt.Concat(password).ToArray();

    var hmac = HMACSHA256();  
    hmac.Key = password;
    var hash = hmac.ComputeHash(saltAndPassword);
    return hash;
}

notice that the key is password, and the hash is generated on salt+password

can we have the password as the key to hash the salt+password, will that comprise security? when using HMACSHA256, do we necessarily have to have a key management inorder to use seperate keys rather than passwords?

also, do keys have to be unique in HMACSHA256?

i know that people often suggest slow functions like - PBKDF2, Scrypt etc..

but is using HMACSHA256 safe too? do people actually use a hmac for hashing and storing passwords? what would be the recommended approach for hashing and storing passwords(if all you have is passwords and unique salts)?

apologies for the parade of questions :) thank you in advance

---

Edit

I couldnt find a way to comment on neither the question or answer(stackexchange requires me to have a 50 rep). so im posting my comment here :

@CodesInChaos hi, thank you for your answer.

HMAC(password, salt + password)

This is silly but harmless. 1) It uses a variable length value as key. HMAC has some >weird properties when doing that. 2) Why input the password twice?

Hmm, should we do something about it?, to make it a constant length value(any recommendations)?

I thought the hash(salt+password) is always better than hash(password) // the sole purpose of salting??

but from what i see from your answer, HMACSHA256 does similar thing using the key supplied?

If you use HMAC for hashing passwords, I'd use the password as message and the salt as >key. This matches HKDF-Extract.

but, in our case salt is the userid, they are exposed, is it okay to use salt as key which are easy to know?.

Answer 1

I know that people often suggest slow functions like - PBKDF2, Scrypt etc..

Listen to them. Use scrypt, bcrypt or PBKDF2. These functions are designed for hashing password. See How to securely hash passwords? for details. This is the recommended approach to hashing passwords.

but is using HMACSHA256 safe too?

It's fast => brute-force is cheaper => it's weaker than a slow hash.

A fast hash is only acceptable if you know that only strong passwords (say 80+ bits of entropy) will be used. In practice this means that you don't allow user chosen passwords and generate them using a computer. At this point they're closer to keys than to typical passwords.

do keys have to be unique in HMACSHA256?

When used as a MAC, keys don't need to be unique. You're using it as a password hash, so there is no secret key. Salts should be unique to prevent multi target attacks, but occasional collisions don't hurt much.

// salt is a guid we store separately, it's the id of the user

This means that the salt will be reused when the user changes their password. Not ideal, but not a big deal either.

HMAC(password, salt + password)

This is silly but harmless. 1) It uses a variable length value as key. HMAC has some weird properties when doing that. 2) Why input the password twice?

If you use HMAC(salt, password) for hashing passwords, I'd use the password as message and the salt as key. This matches HKDF-Extract.

Hmm, should we do something about it?, to make it a constant length value(any recommendations)?

If you use the salt as key and the password as message, the key has fixed length. But since these properties don't have much practical impact, don't worry too much if it's variable length either.

I thought the hash(salt+password) is always better than hash(password) // the sole purpose of salting?

but from what I see from your answer, HMACSHA256 does similar thing using the key supplied?

Since HMAC already combines key and message, you don't need to include the password in both.

but, in our case salt is the userid, they are exposed, is it okay to use salt as key which are easy to know?

Yes, using a public salt as key input to HMAC is fine. You need to make stronger assumptions about HMAC than "It's a PRF", but that's fine.