I had a long discussion with a my colleague Commander Adams today about improving password management policies for Krell Power Systems client logins.
This is a change that would have to be added to the current project backlog, specified and designed, developed, and implemented. Selling this means making a compelling case that salting and changing our hashes would actually solve a problem for us and our clients. My sense is that this is the case, but articulating the case in a unassailable way is still something that needs work.
The most compelling case would be for our clients to demand this as part of their security requirements for our systems. This sword cuts two ways, and a number of our existing password policies are clearly based on well-intended but somewhat misguided client-based requirements. The sane thing is to get good requirements.
Absent that, the question becomes: what is the threat, what is the risk model, what is the mitigation, and what benefits does that mitigation buy us and our clients.
The risk as I see it is disclosure of our user authentication hashes (thank Krell we're not storing cleartext passwords ... at least not there).
Leaking unsalted hashes means that both rainbow tables can be applied against the known hashes, and that duplicate hash instances (hence: duplicate passwords) can be determined and targeted for rainbow/brute force attacks.
A successful attack would gain user access, and might gain access to user information (of varying but largely low sensitivity) and be able to impersonate the user for communications purposes. Some collections of user data might be valuable for contact/communications/social-engineering purposes.
The biggest risk would be for users sharing keys among several services. As a fair number of our clients are corporate, and it's fairly well known that corporate password policies are often even more grossly weak than individuals', the likelihood of compromised passwords being used to access other user accounts in some instances is fairly high.
The question remains: how large are any of these risks?
What does salting and bcrypting buy in way of protection?
My read is that, on the technical side:
- salting hides common passwords within our userbase, and renders rainbow tables useless. Weak passwords are somewhat better protected.
- bcrypt makes the costs of brute-forcing passwords markedly more expensive. Very, very weak passwords could still be cracked, but we're talking on the order of searching through perhaps a few millions of keys -- 4-character alphanumeric mixed-case passwords would be at risk.
- checking proposed (or entered) passwords against a known set of common passwords -- even just a few tens of thousands of the most common ones -- would further reduce low-hanging fruit. Ideally I'd like to see a publicly available corpus of all known passwords, to be used to exclude duplicates.
But again, the question becomes, what demonstrable benefits does this present to us and our clients? How do I make the case?
"What does salting and bcrypting buy in way of protection?"
Information leaks are common: a backup tape gets FedExed to the wrong address, file sharing gets accidentally turned on, a Russian hacker finds a security hole in your machine while scanning millions of machines, some idiot puts the password database on a laptop and loses it. These sorts of problems are constantly making the headlines.
If you have bcrypt-style password encryption, such leaks are a nuisance and embarrassment.
If you do not have password encryption, the leak recipient can easily impersonate any and all users. They can control your system, create false communication, cause industrial equipment to destroy itself, send harassing messages, conduct financial fraud, and so forth.
The cost to use password encryption is a little engineering labor, the return on investment is a substantial reduction in risk.
I've got no question with your first point -- leaks happen. Elements of our hosting environment, regardless of that environment, mean we have lapses in control, whether it's on-site office cabinets, hosted colo, or cloud provider.
Our backups management is pretty solid, with backups encrypted, and even DB systems using on-disk at-rest encryption via an ecryptfs tool.
You did raise the valid point of sensitivity of identity data among some of our clients. While the general case is that PII (personally identifying information) disclosures would largely be embarrassing but not harmful, there are cases in which harm, or even life-threatening risks could arise.
I'm leaning to your conclusion but I'm looking to be able to quantify that more robustly.
And as I noted in my original question: if we were getting pressure from our clients on this, the case would be far easier to make. Market rules.
The trouble with defense in depth is that you have to admit your existing defenses may be inadequate. I can see how that could be politically difficult in a large organization.
Even for a less-than-large organization, there are issues.
One is the perceived fear of looking incompetent in front of your users/clients. For which I feel the appropriate response is "we'll look a lot more competent if we mitigate the risks of such an event than if we don't, regardless of whether or not it happens".
But really, the big one is simply: can you justify the engineering/product cost of this change on the basis of a material business benefit to us and our clients?
This is a change that would have to be added to the current project backlog, specified and designed, developed, and implemented. Selling this means making a compelling case that salting and changing our hashes would actually solve a problem for us and our clients. My sense is that this is the case, but articulating the case in a unassailable way is still something that needs work.
The most compelling case would be for our clients to demand this as part of their security requirements for our systems. This sword cuts two ways, and a number of our existing password policies are clearly based on well-intended but somewhat misguided client-based requirements. The sane thing is to get good requirements.
Absent that, the question becomes: what is the threat, what is the risk model, what is the mitigation, and what benefits does that mitigation buy us and our clients.
The risk as I see it is disclosure of our user authentication hashes (thank Krell we're not storing cleartext passwords ... at least not there).
Leaking unsalted hashes means that both rainbow tables can be applied against the known hashes, and that duplicate hash instances (hence: duplicate passwords) can be determined and targeted for rainbow/brute force attacks.
Leaking non-bcrypt hashes means that brute-forcing is cheap. At some estimates, 3.3 billion keys per second on $1000 of hardware for MD5, roughly half that for SHA1 (http://www.extremetech.com/computing/84314-how-to-secure-you...).
A successful attack would gain user access, and might gain access to user information (of varying but largely low sensitivity) and be able to impersonate the user for communications purposes. Some collections of user data might be valuable for contact/communications/social-engineering purposes.
The biggest risk would be for users sharing keys among several services. As a fair number of our clients are corporate, and it's fairly well known that corporate password policies are often even more grossly weak than individuals', the likelihood of compromised passwords being used to access other user accounts in some instances is fairly high.
The question remains: how large are any of these risks?
What does salting and bcrypting buy in way of protection?
My read is that, on the technical side:
- salting hides common passwords within our userbase, and renders rainbow tables useless. Weak passwords are somewhat better protected.
- bcrypt makes the costs of brute-forcing passwords markedly more expensive. Very, very weak passwords could still be cracked, but we're talking on the order of searching through perhaps a few millions of keys -- 4-character alphanumeric mixed-case passwords would be at risk.
- checking proposed (or entered) passwords against a known set of common passwords -- even just a few tens of thousands of the most common ones -- would further reduce low-hanging fruit. Ideally I'd like to see a publicly available corpus of all known passwords, to be used to exclude duplicates.
But again, the question becomes, what demonstrable benefits does this present to us and our clients? How do I make the case?