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.
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?