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.
Re:Using pepper to increase the security of stored passwords
by mdekkers on Sunday March 03, 2019 @06:39AM
(#19293985)
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.
Re:Using pepper to increase the security of stored passwords
by vince14 on Sunday March 03, 2019 @05:36AM
(#19293786)
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".
Re:Using pepper to increase the security of stored passwords
by mgkimsal on Sunday March 03, 2019 @08:09AM
(#19294270)
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?
Re:Using pepper to increase the security of stored passwords
by larkeith on Sunday March 03, 2019 @04:01AM
(#19293508)
> 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]
Re:Using pepper to increase the security of stored passwords
by larkeith on Sunday March 03, 2019 @04:42AM
(#19293630)
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.
Re:Using pepper to increase the security of stored passwords
by tptacek on Sunday March 03, 2019 @04:38PM
(#19297086)
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.
Re:Using pepper to increase the security of stored passwords
by cheeze on Sunday March 03, 2019 @03:51AM
(#19293473)
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.
Re:Using pepper to increase the security of stored passwords
by cleanyourroom on Sunday March 03, 2019 @10:50AM
(#19294997)
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?
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.
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.
This is not how HN works.
https://imgur.com/a/0W6uQDA
"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?
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.
If you genuinely do
Then on my computer you're looking at 15638751293495759880 combinations, or about 2^64.Pick them from your own day to day vocab and you're more likely in the 2^32 range.
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
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.
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.
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.
Over the years I've found a few annoying password policies that didn't like my prefix, but overall it works great.