12 ms·

Using pepper to increase the security of stored passwords

cheeze 8y ago
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.
- larkeith 8y ago
  That's a good idea - I should start doing that myself, thank you for sharing.
markdown 8y ago
> Error establishing a database connection If you're not caching, you are irresponsible.
snehesht 8y ago
Archive link https://web.archive.org/web/20190303084556/blog.benpri.me/blog/2019/03/03/if-youre-not-peppering-your-passwords-you-are-irresponsible/ https://web.archive.org/web/20190303084556/blog.benpri.me/bl...
larkeith 8y ago
> 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 https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
- himalayanyeeti 8y ago
  To learn more about how passwords are actually secured, consider reading this blog post: https://blog.benpri.me/blog/2019/03/02/reactive-hashing/ https://blog.benpri.me/blog/2019/03/02/reactive-hashing/
  - larkeith 8y ago
    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.
dantiberian 8y ago
The author talks about using SHA-256 as a password hashing algorithm. This doesn’t inspire confidence in the rest of the piece. tptacek in 2016 on peppers: https://news.ycombinator.com/item?id=12550375 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.
- himalayanyeeti 8y ago
  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-using-bcrypt-and-scrypt/ 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/ https://blog.benpri.me/blog/2019/03/02/reactive-hashing/
  - vince14 8y ago
    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".
  - Tade0 8y ago
    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.
cleanyourroom 8y ago
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?
- MattPalmer1086 8y ago
  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.
tptacek 8y ago
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.
- MattPalmer1086 8y ago
  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.
  - tptacek 8y ago
    I'm saying don't do this; it's a cosmetic defense.

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.

larkeith 8y ago
That's a good idea - I should start doing that myself, thank you for sharing.

markdown 8y ago

> Error establishing a database connection If you're not caching, you are irresponsible.

snehesht 8y ago

Archive link https://web.archive.org/web/20190303084556/blog.benpri.me/blog/2019/03/03/if-youre-not-peppering-your-passwords-you-are-irresponsible/ https://web.archive.org/web/20190303084556/blog.benpri.me/bl...

larkeith 8y ago

> 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 https://pages.nist.gov/800-63-3/sp800-63b.html#sec5

himalayanyeeti 8y ago
To learn more about how passwords are actually secured, consider reading this blog post: https://blog.benpri.me/blog/2019/03/02/reactive-hashing/ https://blog.benpri.me/blog/2019/03/02/reactive-hashing/
- larkeith 8y ago
  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.

dantiberian 8y ago

The author talks about using SHA-256 as a password hashing algorithm. This doesn’t inspire confidence in the rest of the piece. tptacek in 2016 on peppers: https://news.ycombinator.com/item?id=12550375 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.

himalayanyeeti 8y ago
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-using-bcrypt-and-scrypt/ 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/ https://blog.benpri.me/blog/2019/03/02/reactive-hashing/
- vince14 8y ago
  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".
- Tade0 8y ago
  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.

cleanyourroom 8y ago

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?

MattPalmer1086 8y ago
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.

tptacek 8y ago

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.

MattPalmer1086 8y ago
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.
- tptacek 8y ago
  I'm saying don't do this; it's a cosmetic defense.