Assuming I'm using bcrypt to digest passwords, is any additional security gained by either encrypting or HMACing the resulting digests? By requiring a key to compare password hashes, I would expect that this would prevent any attempt at brute forcing sans the key.
The keys for this operation are actually stored somewhere other than our application servers, and all cryptographic operations are performed there via API calls. The service is designed to never divulge keys themselves, and only operate on keys by an opaque ID. So it should be considered somewhat less likely that our keys would be compromised in an attack than in typical webapp scenarios. Keys are also unique per customer of our application.
I would normally only consider HMAC for this operation, but this would require extracting (and storing separately) the salt from the bcrypt digest. So simply encrypting the crypt digests seems to be the simplest approach, and intuitively should produce the same desired security properties.
Is this approach reasonable and sane? We already have the cryptography infrastructure in place, so it's not considerably more difficult to encrypt/HMAC our hashes than it is to compute them in the first place. Is there a reason to prefer an HMAC over AES-128-GCM?
