> The problem with it in it's current form is it does not allow for an application pepper.

Considering:

* no password hash algorithm I know of supports peppers

* that the API allows providing a custom salt

I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt and cost already are in the proposed API.

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText);

The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper.

The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code.

If your database is stolen, but your application code is safe the pepper increases the complexity of brute forcing, as they need to work out what the pepper is

The most common pepper algorithm I've seen is doing e.g. "bcrypt(hmac_sha512(password, pepper), salt)" instead of "bcrypt(password, salt)". This has a number of advantages over working the pepper into the hash itself:

1) this wrapper can be applied to any hash scheme, regardless of it's internal structure or options.

2) it doesn't expose the pepper within the hash string.

3) brute-forcing the hash w/o the pepper means you're searching for the 64-byte binary string returned by hmac_sha512. whereas (assuming all inputs are ASCII) "md5(salt+pepper+password)" can still be brute-forced, just treat the pepper as part of the password you're looking for.

> Every hashing algorithm allows it, even bcrypt.

That is not the meaning I intended in my usage of the word "support", but if you equate "support" and "is compatible with", then this API also "supports" peppers, just as much as bcrypt does.

> md5($salt.$pepper.$clearText)

How cute, not just md5 but length-extension vulnerable MD5. I'd recommend not using that scheme for MACs (and more generally not using md5 directly, really, as there are precious few reasons to do so)

> The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper.

Which just happens to be the exact same way bcrypt's API works. Here's an idea: combine the pepper to the password (this is usually done through hmac), not the salt. That's how you use a pepper and remain compatible with the Modular Crypt Format.

> The whole point of a pepper is to keep a second salt out of the database [blah blah blah]

Contrary to your apparent belief, I am aware of what peppers are, how they are used and what they're supposed to do.

A length extension attack is fairly irrelevant for password storage...

If the attacker has one known password in the database, finding the pepper has the same difficulty as finding one password in a DB without pepper.

That is not entirely true: the pepper is usually randomly generated, so a "smart" brute-forcing tool (using combinations and substitutions on a base corpus) will have a much harder time matching something.