is bcrypt improved with hmac'd passphrase?

Question

given:

$salt - a pseudo-randomly generated string of sufficient length

$pepper - a sufficiently strong private key, known only to the administrators of the db where the passphrases are stored

would you see

$hash = bcrypt(hmac($userpassphrase,$pepper),$salt)

being meaningfully superior to

$hash = bcrypt($userpassphrase,$salt)

given the extra burden of managing/storing $pepper as well as $salt?

my assumption is that the hmac does not meaningfully strengthen the resulting $hash, and the burden of storing $pepper outweighs any supposed benefits...but I would love to hear informed opinions.

Answer 1

Keyed hashes, or HMacs, are meant for verifying the source of the data, and not meant for password protection. For example, if you and I had a shared key, I could send some data to you along with the computed hmac, and you could use that same key to check if the hmac hashes match, and if so, you know the data came from me, and hasnt been altered.

There is no way for you to effectivly hide a secret passphrase on the machine that an attacker could not get to, all you'd be doing is adding a layer of obscurity. Using an HMac, without having a shared secret key, is essentially the same as doing SHA($userpassphrase, $salt), which is very easy to compute, and therefore would not add any meaningful security to your password hashing scheme once the "secret" passphrase is known.

The whole point of bcrypt is just to slow down the hashing process, so it would take an attacker a long time to generate a rainbow table for your salt. If you want to make your password hashing scheme more secure, just increase the cost of the original hashing function. In bcrypt, you can specify the number of "logRounds" (I think that's what they called it) which is the number of times the hash is performed. If you specify a logRounds of 15 (10 is the default), then the hash will be performed 2^15 = 32768 times, which slows it down significantly. The longer it takes to perform the hash, the longer it will take for an attacker to break it.

Answer 2

I'm not sure how you'd want to use it. Assuming you store $hash to do a challenge-response authentication later then you'd need to get the $pepper to the client and it would just be another salt. Simply adding an HMAC there will not be of much use.

Answer 3

There's no point tacking an extra hash onto a password stretching function like bcrypt; it'd be easier and better to just iterate it another couple of times.

The 'pepper' is a commonly used but questionable practice; personally I'm of the opinion that the attack models under which an attacker obtains your database but not access to you secret key are sufficiently contrived that protecting against them is not worth the implementation complexity that results.