SoylentNews is people
SoylentNews
You heard me. You know how weak your user’s passwords likely are. You know your users are almost certainly sharing their passwords with multiple sites. You know that a compromise of your database could lead to significant damage coming to them. You know this because it happens all the time, all over the web.
You have a duty to protect the security and privacy of your userbase. They’ve entrusted you with their data, and it is on you to keep it safe. So why aren’t you doing everything possible to accomplish that task? For this blog, we are going to talk exclusively about password storage.
If you ask just about any security professional in the world how best to store a password, you’re liable to hear something about using a cryptographically secure hashing function “with a salt.” Some will go so far as to mention algorithms like Bcrypt or Scrypt. Very few will make any mention to how password policy plays a significant part in ensuring the security of any stored values.
But almost none of them, will even mention the word “pepper.” Now I suspect this isn’t malicious, (obviously). I think even most security professionals simply aren’t informed enough to know or act with regard to this concept.
So today we’re gonna work on that…
(Score: 2) by JoeMerchant on Tuesday March 05 2019, @06:25PM (2 children)
I guess that depends on your definition of "good idea." My pre-requisite for spending resources on pepper is that the rest of the system is in good shape to start with, not that you use pepper as a band-aid to cover up horrible existing security problems. If your attackers are getting not only one, but multiple database dumps, and yet, somehow, your single pepper value remains secure, then yes, I agree that multiple secure pepper values would be "less secure" when the attacker has multiple database dumps. I would hope to dog that your pepper values are at least 128 bits, preferably 1024 bits or more... so, whereas an un-peppered database has 0 bits of pepper security, and a single 1024 bit peppered database has 1024 bits of security, if a rotating pepper changes daily and an attacker manages to get copies of the database every single day for 3 years running, that would reduce a 1024 bit pepper to roughly 1014 bits of security...
My premise is rather that nothing, including your pepper values, are 100% secure, so, if you happen to exfiltrate a pepper value or two, and also manage to exfiltrate a copy of a peppered database (presumably this is harder to do without being noticed...), the probability of the pepper you have matching the database you have would be something less than 100% - net increased security vs a fixed pepper.
Everything depends on circumstances.
🌻🌻 [google.com]
(Score: 2) by meustrus on Thursday March 07 2019, @03:32AM (1 child)
Ah, the detail I was misunderstanding was stealing the pepper at a different time than the database. Rotating your pepper would indeed improve that situation.
This just reminds me of how hard it is to do security right. Everything you can do has trade-offs, and it's not always obvious when doing something to make it more secure actually makes it less so. I'd be interested in a more in-depth discussion of the trade-offs inherent to protecting passwords in a database from leaks.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by JoeMerchant on Thursday March 07 2019, @04:18PM
As I closed with "everything depends on circumstances..."
Someone else pointed out, quite correctly, that to rebuild the database with different peppers, if you are using non-reversible hashes then you will need to keep an un-peppered copy of the database somewhere... it's possible that this "somewhere" might be substantially more secure than where the live database is stored, or not...
Of course one could simply apply the pepper as an XOR to the salted passwords in the database. Then, you would only need the current pepper and the new pepper in order to update the database to the new pepper. If multiple copies of the database are being illicitly obtained and the peppering pattern is known, this might make it easy to un-pepper the database, but with a little cleverness - such as a very large pepper (perhaps generated from a "secure" PRNG?) where only small parts of the pepper are applied to each salted password...
The reality of the situation is: how widely is this algorithm being applied, and by extension: how many people are actively attempting to break it? If you're trying to secure your algorithm against an onslaught of thousands of determined and well resourced attackers, you'd better have a pretty large and clever team helping to design and test it. If you're running a single backwater corporate website that might have 10 or less attackers focused on it over the next several years, you'll probably get better security with a smaller team that has less "human factors" involved in protecting the secrets.
🌻🌻 [google.com]