What is the right way to implement Keyed Password Hashing?

Question

As mentioned in this wonderful link, the way to get a PBKDF2 Hash of a user given password given

1. a password (of course),
2. a salt (generated Cryptographically Secure Random Number Generator.
3. iteration count (chosen high enough to be secure while balancing your application's usability tolerance)
4. Hash size (length of the hash to be computed)

/** * Computes the PBKDF2 hash of a password. * * @param password the password to hash. * @param salt the salt * @param iterations the iteration count (slowness factor) * @param bytes the length of the hash to compute in bytes * @return the PBDKF2 hash of the password */ private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes) throws NoSuchAlgorithmException, InvalidKeySpecException { PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, bytes * 8); SecretKeyFactory skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM); return skf.generateSecret(spec).getEncoded(); } Now my question is :

How should the Keyed hashing for the password be implemented ?

Based on my reading, this is my line of thinking. Please validate.

• Keep the salt argument to the method pbkdf2 (in the code snippet above) secret (obtain it from a highly secure HSM as opposed to storing it in the database alongside the password hash when needed).

• Since the salt is meant to be random (to protect them from the rainbow tables / dictionary attacks), the salt provided to the pbkdf2 should be a concatenation of the key and a random bytes generated from a CSPRNG.

  [salt] = [secret key] + [random bytes from a CSPRNG]

Finally, I will dare to ask a silly question (will dare to ask since high iteration count is posing a serious usability issue since we need to authenticate for 90% of the use cases in our application)

Can we reduce the iteration count OR do without it since we have added an additional layer of security through the Keyed hashing ?

P.S: I am aware of the value that slow hashing algorithms add by reducing the possibility of passwords getting compromised through brute force attacks. Just want the experts to comment on the security value addition through Keyed Hashing VS having a Slow Hashing algorithm with non-secret salt.

Answer 1

One way to combine password hash with a secret key is to have a separate device (i.e. HSM) which encrypts password hashes sent from auth server using a key only known by the device itself.

At user login, your auth server calculates a slow hash (say, bcrypt) with proper cost setting (whatever is tolerable for the server/situation, 5ms, 20ms, 100ms?) and passes the resulting hash to the encryption device, which in turn returns the encrypted blob which you can verify on the auth server (auth server stores hash identifier, cost, salt, possible "encryption device key identifier material" and the encrypted blob).

The "encryption device" will not allow the auth server to decrypt hashes, only encrypt and return the encrypted blob to auth server.

The separate key adds another layer of security if it is not under the same thread model than the auth server/hash database.

Using a separate, narrow access device which holds a strong key defeats attacks that get hold of the leaked user database (and auth server files).