- The nonce for the hmac value is designed to be stored on the file system and not in the databases storing the password hashes. In the event of a compromise of hash values due to SQL injection, the nonce will still be an unknown value since it would not be compromised from the file system. This significantly increases the complexity of brute forcing the compromised hashes considering both bcrypt and a large unknown nonce value
- The hmac operation is simply used as a secondary defense in the event there is a design weakness with bcrypt that could leak information about the password or aid an attacker
I thought this was interesting as well. The second bullet is a bit misleading though. The benefit is not just in case there is a design weakness in bcrypt. The real benefit is briefly summarized in the first bullet: It's effectively forcing the attacker to compromise not only the database but also the file system to be able to make any offline password guesses.
With bcrypt alone, compromise of the password hashes still allows brute-force offline dictionary attacks. bcrypt means that each guess might take, e.g., milliseconds instead of microseconds, but an attacker has all of the information he needs to make offline guesses and check them against the compromised hash.
The hmac step means that an attacker who has the password hashes but not the hmac nonce effectively doesn't get any offline guesses. Assuming the nonce is e.g., 128+ bits, it'll be computationally infeasible for the attacker to guess the nonce itself, without which he can't verify any offline password guesses.
What I've been doing for quite a while is fairly similar. Instead of simply using a salt for each password I also have a random "site salt" (file system nonce), as follows:
hash(password_plaintext + salt + site_salt)
Assuming an attacker can't access my site salt, is this less secure than using HMAC+bcrypt? (my hash function is fast)
https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#...
- The nonce for the hmac value is designed to be stored on the file system and not in the databases storing the password hashes. In the event of a compromise of hash values due to SQL injection, the nonce will still be an unknown value since it would not be compromised from the file system. This significantly increases the complexity of brute forcing the compromised hashes considering both bcrypt and a large unknown nonce value
- The hmac operation is simply used as a secondary defense in the event there is a design weakness with bcrypt that could leak information about the password or aid an attacker