6 ms·
Split brain your password storage. Another table, another database or another storage system in general. If an attacker SQL injections your database don’t go
by odammit 9y ago
Split brain your password storage.
Another table, another database or another storage system in general.
If an attacker SQL injections your database don’t go spilling every hashed or unhashed password you’ve got.
I tend to store passwords in a separate keyvalue store from where my authentication identifier is (email, “username”).
If someone gets into my network they need to get into my servers with the email addresses and then get into a secondary system where the passwords are stored.
I like my password systems to be a k/v store because there is no need to “query” it. I usually store the password under a key that isnt the identifier. Instead using something like a database surrogate key.
Have a secondary system (microservice, private subnet) that simply returns a boolean representing if the provided non-email (key) and password (value) match.
Have that secondary system take the plain text password so it can do the hashing without letting the dependent service know what algorithm, salt or stretches you’re doing. This will also allow you to easily roll over to new hashing algorithms over time without affecting the service that is doing th authenticating.
Edit: I’m not trying to be a know it all or a crabby old tinfoil hat a-hole. But it’s passwords, man. When you leak them you ruin people’s days/year/life. Building that system above takes a middle of the road engineer a day or two. Put the effort in. Every password leak makes all of our jobs harder. It’s your companies responsibility to keep that safe. If you know that already, be the annoying guy that brings it up in every stand up. Make that debt known.
- professorTuring 9y agoRule n1: don't roll your own security. Rule n2: goto 1 You are overcomplicating your authentication system by oversimplifying security problems and the result is that you have solved nothing. Security always seems very easy to solve and usually non-security engineers tends towards solutions like yours that doesn't provide extra security, they just add a few extra steps for a hacker to obtain you database and as a result you need to maintain extra databases, there are more error points... Do you remember that thing about "each extra system exponentiates complexity"?
- odammit 9y agoYou don’t have to “roll your own security.” You can easily put any open source security system behind a secondary system. Hell - it would already be a secondary system. Not putting your passwords right next to the identifiers is a simple way to lower the impact of an email or password leak. Also, that quote is bullshit.
- professorTuring 9y agoMeh... I won't bother. Discuss your solution with a security guy you trust.
- jaequery 9y agogo a step further and you will get into key management devices like the HSMs and/or the Amazon KMS. KMS cost almost next to nothing and it is pretty neat since its a web service, especially coming from the world of $40k+ Thales/Safenet HSM devices which are a pain to deal with (backups, rehash, redundancy).
- sah2ed 9y agoMind sharing how you currently use Amazon KMS in practice?
- jaequery 9y agoIt was to meet the PCI-DSS Level-1 security standards for banking compliance. We'd store encrypted cards in one place and store the master keys in the AWS KSM to later decrypt it. But to retrieve the master keys, it goes through another layer of encryption.
- ksenzee 9y ago> don’t go spilling every hashed or unhashed password you’ve got. Please don't store unhashed passwords. By now even PHP gives us the tools to do this right. You truly don't need secondary systems, or separate tables, or separate anything. Just hash the passwords.
- odammit 9y agoYou need both. https://www.trustedsec.com/2016/06/introduction-gpu-password-cracking-owning-linkedin-password-dump/ https://www.trustedsec.com/2016/06/introduction-gpu-password...
- grzm 9y agoAll security decisions boil down to your threat model, doesn't it? At some point there are decreasing marginal returns with increasing security. What threat models are you satisfying with the strategies your proposing? Do you think these apply to everyone? Or even everyone who stores hashed passwords? I personally don't think so, but I'm interested in hearing about things I haven't come across yet.
- odammit 9y agoA day of engineering effort to make exposing passwords much more difficult. Yes. If you’re a company that stores someone’s password. You know they probably use it elsewhere so it’s your responsibility to help keep it safe. Also I left the link off above ^
- zaarn 9y agoI would argue that the benefit of putting all the hashes into a separate table is not really worth it. A separate service just to verify passwords sounds an awful lot like reinventing LDAP or AD/Kerberos with less features. It should be good enough to simply encrypt the password hashes with an application-side key, a simple database dump won't leak passwords anymore. If your passwords are properly hashed and stretched with appropriate and modern functions (SHA2/3 and Argon2) and encrypted-at-rest (Chacha20 or AES256) then you should be sufficiently equipped to secure your customers passwords against most attacks.
- brazzy 9y agoSorry, but this is convoluted nonsense that can only achieve one thing: make yourself more vulnerable. You want your security system to be as simple as possible, and to involve as little custom code as possible. Because you can and will fuck it up if you try to be clever. Hash and salt your passwords using a library designed exactly for that purpose (which means it will use a slow hash). That's it, end of story.
- professorTuring 9y agoAgree.
- odammit 9y ago^ above is pretty damn simple. I also never said “write your own hashing algorithm” I said abstract it so it’s not sitting around in your ecommerce app code. That is a simple security system. It’s just not baked into your flagship ecommerce, blog or whatever else your storing the credentials to protect.