Consider supporting a pepper

[tjconcept]

http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough

Test the impact on hashing performance.

[Sc00bz]

Pepper is actually a "non-cryptographic salt" (e.g. username), but recently (2012-2013) has been stolen to mean a server secret (i.e. key). Note that most say to use a "pepper" as some kind of keyed hash. This is wrong. You should always use this key to deterministically encrypt the hash part. NULL-IV-CBC-CTS is ideal. Yes this will make cryptographers shit their pants until they realize that you are encrypting cryptographic random data. They might still have issues because this is non-standard but there are no attacks... if you encrypt binary data and not ASCII encoded data. This also lets you use an HSM to just encrypt and then you compare the output. Also if the hashes are stolen you can re-encrypt your hashes under a new key to make the stolen hashes worthless. Unlike with keyed hashing, which need to be rehashed on login, password reset, or password change.

I've been meaning to finish a blog post about this and that new API functions for password authentication should be like:

string hash(string password, [function encryptHash, ["params" encryptHashParams]])
bool verify(string password, string hash, [function encryptHash, ["params" encryptHashParams]])
blob encryptHash(blob hashPart, int maxOutputLength, "params" encryptHashParams)

Anyway switching to bcrypt is 1000x better... really 40x better. Well Node's PBKDF2-SHA512 is compiled vs bcrypt which will be interpreted JS. So only 4x? better.

[tjconcept]

This is wrong

Can you elaborate on this?

just encrypt and then you compare the output

If the output of the encryption is deterministic, what is the difference from hashing? I suppose an attacker would brute force against the pepper in both situations?