Correct me if I'm wrong, but an algorithm is a set of steps, which this looks like to me

    salt = urandom(16)  
    pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q"  
      # or,        getenv('PEPPER')  
    hashed_password = scrypt(password, salt + pepper)  
    store(hashed_password, salt)

That is an algorithm, which composes bcrypt with pepper.

The idea of not using key-rotation alone is insane, but lets just focus on your last point

    Also, I'm confused at how the proposed alternative would be harder to get wrong

Really? AES literally has hardware support, and can be done in a single call, and has been studied for years. How can that reasonably be considered "harder" to get wrong than something proposed by some random guy on the interwebs?

Outside of Peer-Review, what reason would anyone have to use the pepper scheme? As others have posted, there are several community members who's opinions do matter due to extensive research and body of work

Your second point might be dangerous - your salt values are no longer random but heavily biased and knowing that all salt values share some common bits might provide a new attack vector.

Is this true? I would think that static bits are no more dangerous than not having the bits at all.

Here is for example an attack recovering a 384 bit ECDSA key [1] by knowing the five least significant bits of the nonce (obtained by a side channel attack) for 4000 signatures. Now hashes and signatures are obviously very different things but I would not bet on the fact that a bias in the salt does not matter.

[1] https://eprint.iacr.org/2013/346.pdf

ECDSA is a completely different beast. I'm not aware of a modern password hashing function that would be broken if it was given a non-uniformly random salt. If such function were to be submitted to PHC (https://password-hashing.net/), I would consider it to be a disqualifying factor.

For password hashing purposes, salt doesn't need to be uniformly random, the only requirement for salt is to be unique and unpredictable to the attacker (see http://crypto.stackexchange.com/questions/6119/hashing-passw...). Most password hashing functions use a cryptographic hash on salt.

This particular function, scrypt, uses one-round PBKDF2-HMAC-SHA256 to mix password and salt:

https://github.com/golang/crypto/blob/master/scrypt/scrypt.g...

PBKDF2 feeds salt, basically, into SHA256:

https://github.com/golang/crypto/blob/master/pbkdf2/pbkdf2.g...

If there was a known attack it would obviously be a non-starter. But why take the risk that someone will come up with something comparable - in the broadest sense - to say the differential attack on MD5 that allows exploiting known bits in the salt if there is no need to?

Interesting. Thanks for the link!

> 2) It's not abusing the algorithm, it's using a longer salt (in the concatenation case).

But PBKDFs like bcrypt and scrypt are not designed to keep the salt parameter secret; in fact they assume the attacker knows the salt. And so if they happen to reveal the salt to the attacker, this is not considered a bug in the algorithm and won't have been flagged or fixed by cryptographers.

(And more importantly in practice, the implementations of these algorithms aren't designed to keep the salts secret.)

The "concatenation case" completely defeats the purpose of using a pepper and leads me to believe that you're not qualified to be giving this kind of advice.

In what way it defeats the purpose of using a pepper?