It seems like all the articles, videos and papers I can find about password peppering are missing a better method to implement them. I would appreciate a reality check.
This can be valuable whether you think peppers are good or bad. If you think they're good, this might be a better method to use them. If you think they're bad, this might be a stronger version to argue against. The point of this post isn't to endorse peppers, but to compare the common methods to an alternative one.
Note: I'm not a cryptographer, take this with a grain of pepper.
Terms and background, in short
Skip if you're familiar
Hash: Secure password storage doesn't store passwords, so if the database leaks, the passwords aren't revealed. Instead you use a hashing function, which takes any password, and turns it into a seemingly random (very large) number, this is your hash, and this is what you store instead of the password. Hashes are hard to reverse, and unlike encryption, hashes don't have keys to decrypt them. When the user logs in, the password is hashed again and compared to the stored hash.
Salt: A random string that is added to to the password before it's hashed, and is usually stored in plain text near the now salted hash. When the user logs in the salt is again hashed with their password and compared to the stored hash. Salts prevent rainbow table attacks, and make the hashes of passwords shared by multiple users unique so each password has to be cracked individually.
Pepper: A pepper is a secret salt that doesn't get stored in the database (at least not near the user), or not stored at all. Peppers make it harder to crack individual passwords even in the case of a leak.
There's two main approaches to peppering, both should be in addition to salts.
- You generate a really long number (128+ bits) and store it outside the database, then whenever you need to hash a user's password you add it to the password before hashing.
- Pros: if attackers don't know the pepper it's impossible to crack any of the passwords.
- Cons: If the attackers find the pepper it becomes useless, and if they know the salt and plain text password of some user (could even be themselves), and which hashing algorithm was used, they can potentially use that to brute force the pepper.
- You pick a string at random and use it a the pepper, but don't store it at all, so every time the user logs in you basically have to brute force all the peppers until you find the right one. For it to not take ages, you use a small string, say 1-2 characters.
- Pros: It makes the attackers X times slower because they have to try every possible pepper on each password.
- Cons: the attackers will likely know which peppers are possible, since it's likely 1-2 characters out of the allowed character set. And users that got letters that hackers are likely to start with just out of convenience are at a serious disadvantage.
My method is a combination of the two:
Do note that I'm not saying no one has come up with this before, just that I didn't see it.
Generate some (say, ~100) really long numbers, and store them outside the database. When a user registers, you pick one of them at random and use it as their pepper. Whenever they login you try each of the stored peppers until one works.
Pros over #1:
- Your peppers aren't easy to crack anymore, even if one pepper is brute forced, there's still all the other that remain unknown.
- If the peppers leak, then the attackers still don't know which pepper is used for which user, and so are still slowed down by the amount of peppers you chose to generate.
Pros over 2#:
- The peppers are practically impossible to guess, while still giving the benefit of having a lot of different ones.
- This makes cracking even a weak password like '123' impossible without already knowing the pepper used or which peppers to check.
- Authentication isn't slower since appending is quick and you choose the amount of peppers you use.
- You don't lose much security from stored peppers since the possible peppers were already quite predictable with the common method.
- You have better control over the amount of possible peppers, and it's easy to gradually add more peppers with time.
I think this should be more secure than both methods, with little downside, and barely any increased complexity - Yet I wasn't able to find any source that describes something similar.