Using pepper to increase the security of stored passwords(blog.benpri.me)
blog.benpri.me
Using pepper to increase the security of stored passwords
https://blog.benpri.me/blog/2019/03/03/if-youre-not-peppering-your-passwords-you-are-irresponsible/
7 comments
You might be interested in why I feel this way. I actually have a pretty strong anti-bcrypt bent. Not to just point back to my blog again, but I've written two anti-bcrypt posts which may be viewed here:
https://blog.benpri.me/blog/2019/01/13/why-you-shouldnt-be-u...
and here:
https://blog.benpri.me/blog/2019/03/02/reactive-hashing/
Your first post is very dishonest and misleading. In conclusion you are comparing long vs short passwords but attach the hash algorithms to them to fit your narrative. Both points in conclusion are wrong and as noted in the comments: you would run a dictionary attack on your chosen longer password. Which is a bit ironic because this "lulls you into a false sense of security".
color me stupid but I didn't understand
"You should not be using Bcrypt. You should be using passphrases."
These seem orthogonal to each other. How would you store the 'passphrases'? in plaintext? or hashed? if hashed, what hashing algorithm? Why not bcrypted passphrases?
"You should not be using Bcrypt. You should be using passphrases."
These seem orthogonal to each other. How would you store the 'passphrases'? in plaintext? or hashed? if hashed, what hashing algorithm? Why not bcrypted passphrases?
I read the first article.
Passphrases give us the ability to easily remember high entropy password values.
Passphrases are not high entropy once you take into account that they're words in a specific language.
Passphrases give us the ability to easily remember high entropy password values.
Passphrases are not high entropy once you take into account that they're words in a specific language.
Depends how you pick them.
If you genuinely do
Pick them from your own day to day vocab and you're more likely in the 2^32 range.
If you genuinely do
grep "^[a-z]*$" /usr/share/dict/words|shuf -n 4
Pick them from your own day to day vocab and you're more likely in the 2^32 range.
This doesn’t inspire confidence in the rest of the piece.
The title doesn't inspire confidence in the rest of the piece. Why is it that increasingly, people feel compelled to put such a negative spin on content. Another "if you don't do <something I feel strongly about>, you are <something negative>" piece. If what you are writing needs some clickbaity title, I'm not interested.
I have not heard of peppering before, and if the author would have titled something along the lines of "peppering significantly improves the security of your stored passwords" I would have been all over it. Now the author has already called me "irresponsible", and he doesn't even know me. Well, fuck that guy, I'll find somewhere else to read about what specific seasoning I should be applying to stored passwords. What an ass.
EDIT He just changed the title.
The title doesn't inspire confidence in the rest of the piece. Why is it that increasingly, people feel compelled to put such a negative spin on content. Another "if you don't do <something I feel strongly about>, you are <something negative>" piece. If what you are writing needs some clickbaity title, I'm not interested.
I have not heard of peppering before, and if the author would have titled something along the lines of "peppering significantly improves the security of your stored passwords" I would have been all over it. Now the author has already called me "irresponsible", and he doesn't even know me. Well, fuck that guy, I'll find somewhere else to read about what specific seasoning I should be applying to stored passwords. What an ass.
EDIT He just changed the title.
OP changed the title on HN but his blog still has the original title.
This is not how HN works.
https://imgur.com/a/0W6uQDA
This is not how HN works.
https://imgur.com/a/0W6uQDA
Don't do this. The entire premise of a password hash is that the authenticator, in its entirety, is disclosed; the job of the password hash is maximize the cost of backing the authenticator out to the password itself.
Of course, it's good to make it harder to exfiltrate the authenticator! And that's really what things like "peppers" are trying to do. But if you're going to build up that defense, be serious about it: move the password hashes entirely out of the application and its accessible storage (don't just spread it across two different kinds of storage the application already has access to!).
So, rather than pretending like you're improving security by keying the password hash, just stand up an authentication service. Give it "verify(user, password) bool" and "enroll(user, password)" and nothing else. Write it in a managed language with a minimal runtime (Rust, Go, or Java, no framework). Then, before you ever think about monkeying with the hash constructions themselves, get to work on segregating it out so that it's in its own AWS or GCP account, enforces rate limits, &c. You will never run out of better ways to secure the authentication services than this "pepper" nonsense.
Of course, it's good to make it harder to exfiltrate the authenticator! And that's really what things like "peppers" are trying to do. But if you're going to build up that defense, be serious about it: move the password hashes entirely out of the application and its accessible storage (don't just spread it across two different kinds of storage the application already has access to!).
So, rather than pretending like you're improving security by keying the password hash, just stand up an authentication service. Give it "verify(user, password) bool" and "enroll(user, password)" and nothing else. Write it in a managed language with a minimal runtime (Rust, Go, or Java, no framework). Then, before you ever think about monkeying with the hash constructions themselves, get to work on segregating it out so that it's in its own AWS or GCP account, enforces rate limits, &c. You will never run out of better ways to secure the authentication services than this "pepper" nonsense.
I wouldn't say don't do this, although you do have to spend your security resources carefully.
While it only provides additional security against password database exfiltration attacks, it is also a very, very low cost mitigation.
It could equally be used in a separate authentication service as one of the many ways to harden it.
While it only provides additional security against password database exfiltration attacks, it is also a very, very low cost mitigation.
It could equally be used in a separate authentication service as one of the many ways to harden it.
I'm saying don't do this; it's a cosmetic defense.
Wouldn’t an attacker only have to manage to bruteforce 2 of the hashes in order to discover this pepper, which would just be the text that is common between them?
If they could brute force just one hash they would know the pepper. But this is already infeasible if the pepper has sufficiently high entropy.
I do this for my super important accounts in my password manager. I have a simple prefix that I use which isn't stored in my password manager, such that if my manager got compromised they still wouldn't have my banking/email passwords.
Over the years I've found a few annoying password policies that didn't like my prefix, but overall it works great.
Over the years I've found a few annoying password policies that didn't like my prefix, but overall it works great.
That's a good idea - I should start doing that myself, thank you for sharing.
> It’s very likely that a lot of your user’s passwords are going to be cracked
While I agree that peppering your passwords is good practice, this is just flat-out wrong - with a salted modern hash algorithm it should be cryptographically infeasible to crack passwords from a database dump, and if you are using an insecure algorithm, it is just as easy to recover the pepper as the passwords.
> Very few will make any mention to how password policy plays a significant part in ensuring the security of any stored values.
As a reminder, the NIST recommends enforcing only minimum length and known-vulnerable password requirements: "Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets." [1]
[1] https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
While I agree that peppering your passwords is good practice, this is just flat-out wrong - with a salted modern hash algorithm it should be cryptographically infeasible to crack passwords from a database dump, and if you are using an insecure algorithm, it is just as easy to recover the pepper as the passwords.
> Very few will make any mention to how password policy plays a significant part in ensuring the security of any stored values.
As a reminder, the NIST recommends enforcing only minimum length and known-vulnerable password requirements: "Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets." [1]
[1] https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
To learn more about how passwords are actually secured, consider reading this blog post: https://blog.benpri.me/blog/2019/03/02/reactive-hashing/
Dynamically adjusting the hash count is an interesting idea (though I would strongly recommend using a better measure of entropy than password length alone), but I'm not really sure how this answers my concerns - as attackers will generally have at least one known username-password combination, it is trivial to recover the pepper if the database is not strongly enough hashed. If you use high password complexity as an excuse to lower hash counts, you only make it easier for attackers to recover the pepper.
It also doesn't really address the root failure of password policies, in that many users will simply pad passwords with required characters and/or be more likely reuse a single password that fulfills standard requirements. Comparison against lists of compromised/vulnerable passwords remain a better way to ensure complexity, preferably in combination with a password strength meter.
It also doesn't really address the root failure of password policies, in that many users will simply pad passwords with required characters and/or be more likely reuse a single password that fulfills standard requirements. Comparison against lists of compromised/vulnerable passwords remain a better way to ensure complexity, preferably in combination with a password strength meter.
tptacek in 2016 on peppers: https://news.ycombinator.com/item?id=12550375
The current best practice of simply hashing passwords with bcrypt is fine, and anything past that which doesn't doesn't involve (probably per-password) use of an HSM adds only marginal value.
I wouldn't want anyone to read this and get the impression that "secret peppers" and multiple hashing rounds and HMAC were important components of a password storage system. They are not: they're things that message board nerds come up with.
If you want to be a step better than just storing passwords with bcrypt, your next step is to create an authentication service that runs on separate hardware with an "is this password valid" and "enroll this password" API and nothing else. The stuff people do instead of this is basically cosmetic.