[rudolf0]

A properly implemented, simple pepper can only help password security and can't hurt it. Obviously you first must be using a good, slow algorithm (bcrypt, scrypt, or PBKDF2 with high work factor), but a pepper will only help you. (Let's assume the pepper is an AES key which all hashes are encrypted with.)

Yes, many times a dedicated attacker who has read access to your database will also have read access to your source code or config files, but many times they won't. And if they don't, then they won't be able to crack a single one of your passwords, while even with a modern and proper hashing algorithm they still may be able to crack passwords.

Take the scenario of a relatively intelligent hacking or hacktivist group, of which there've been several in the past 5 years. Let's say they're targeting someone they dislike for whatever reason, and find out that person is registered on some forum and decide to compromise the forum. (This tactic of lifting a whole haystack to find a single needle is very common for motivated attackers.) They don't care about any of the other users, they just want to try and crack the hash of one single member and have a full GPU cluster with which to do it. They're also willing to spend weeks trying to crack that one hash.

If the user's password isn't particularly strong, it's going to fall no matter what algorithm they used.

But if the forum is peppering all of their hashes, and those same attackers can only manage to gain access to the forum's database and not its local filesystem, then their chance of cracking that password goes to 0.

This scenario is a bit contrived because odds are motivated and intelligent attackers like these will end up gaining access to the filesystem and reading the pepper with enough time and effort, but the pepper is still an additional defense and means SQL injection alone won't be enough to crack passwords.

[specialk]

Hey thanks for the long response. I totally get the premise of peppering I think my problem is with this sentiment "A properly implemented, simple pepper can only help password security and can't hurt it".

From all the advice I've read security and crypto they don't work like that. The assumption is the other way around. A properly implemented, simple pepper can only hurt password security until proven otherwise by rigours testing and analysis.

Time and time again we read stories of a tiny implementation detail that created a sly and subtle vulnerability that simehow leaks information about original plain text by interrogating the cipher text.

bcyrpt with a large work factor and a per user salt is a PROVEN method to prevent attackers learning the plain text. Until I see evidence from a trusted cryptanalyst I'm not going to roll my own by adding in pepper they didn't plan on being there.

EDIT: sorry let me make my point a little clearer. In the event that the hacker can access the filesystem or memory -- whereever you store your pepper -- could the hacker use the pepper and an implementation detail in the peppering technique to learn information about the plaintext or the salt? This question is what needs to be answered by qualified cryptanalysts before developers start using peppers wide-spread in my opinion.

[rudolf0]

I would argue that while crypto most certainly works that way (use only when definitively proven), security in general is a bit more lax in terms of requirements.

Despite hashes being cryptographic primitives, user password hashing is less about cryptographic principles (preventing first and second preimage attacks) and more about increasing the amount of work an attacker must muster to find an input which hashes to the hash value.

Attributes like collision resistance generally mean almost nothing when on the scale of strings under 100 characters in length, which most user passwords are. Practically, you are never going to run into collision issues if you're using MD5 or later. Your goal is merely to increase the amount of CPU time it takes to find a hash's original input.

Because of this, even if AES encrypting a hash with a random pepper somehow reduced the collision resistance of a hash (I'm 99.8% sure it doesn't), it wouldn't at all affect the speed at which the hash is cracked.

>a sly and subtle vulnerability that simehow leaks information about original plain text by interrogating the cipher text.

Hashes are not ciphertext. For all intents and purposes they can be viewed as CSPRNG output. There is nothing you could do to them to leak info about the plaintext as long as your hash algorithm isn't pathological. There are things you could do to reduce collision resistance, but I addressed that above.

Password protection in web apps is not about encryption or decryption.

[ircmaxell]

> A properly implemented, simple pepper can only help password security and can't hurt it.

Well, yes. But what is the definition of "properly"? There are definitely constructions of "pepper" that look simple, but drastically hurt overall security:

    bcrypt(hmac(password, key), salt)

If hmac returns raw bytes, you're in real trouble: http://blog.ircmaxell.com/2015/03/security-issue-combining-b...

It's sort of like the difference between birth control and counting based contraceptive methods (Standard Days Method). Executed perfectly, they are equally as effective. But with a slight error, one stays roughly as effective (losing maybe 5 to 10% effectiveness overall) while the other drops drastically (down to 10 to 20% effectiveness).

Considering using encryption is as effective as using a pepper, and it's less prone to weakening the core password hash, I suggest using encryption instead of peppers.

[rudolf0]

I am well aware of that misuse, as I've exploited it during a CTF before. :)

I would consider using the raw byte-output version of a function a very blatant example of "improper implementation".

Also, I agree regarding encryption. In my example I was actually referring to the random AES key as a pepper, even though it'd probably be better called an "application secret".