Plain-text password storage is good

…or at least, not as bad as it’s sometimes made out to be.

Please note that I am not discussing any password system used by any employer, past or present. This is based on general industry knowledge only, and is meant to explain why so much software suggests or requires plaintext passwords to be stored.

When I first came across a professional application that used plaintext password storage (about six years ago now) - I thought, “Ugh, why would anyone store passwords cleartext?”. There are a huge number of really valid reasons why not to - the easiest one being simply “what happens if/when that database gets stolen?”. You may or may not be concerned by “Can the server admins and developers see my password?”. I found out why the hard way when I tried to do something similar, maybe a year or so later.

So, why would a sysadmin or software developer choose to use cleartext password storage, with the risks that it inherently has? The same reason as with most security issues - it’s overridden by convenience and usability. Password security has two main aspects; protection when stored, and protection when in transit.

In-transit seems pretty easy, but has quite a few pitfalls. A horribly common mechanism is just to pass it cleartext. Eww! Another is to pass it reversibly encrypted over SSL. Better - man-in-the-middle snooping is stopped - but still not really great. What about only sending an MD5 across the wire? Challenge-response systems are yet another solution - the server sends you a secret string, you combine it with your password in a way predictable to the server and send a munged ‘response’ back to the server. Great, right?

No. Your average challenge-response system uses a function along the lines of MD5(challenge+MD5(password)). So for both of the last two options, all the server needs to store is the MD5 of the password, instead of the password itself. Win. Except for the fail that you’ve just made your MD5 of your password valuable, because that’s all the attacker needs now - and that’s exactly what the server is storing!

Moving back to storage - what sort of authentication systems does your software use, and what do you need to store to support it? CRAM-MD5? Plaintext over the wire? APOP? Something custom? MD5? CHAP? What happens when CRAM-SHA256 displaces CRAM-MD5, and you’re only storing an MD5? You can only use the authentication methods compatible with what you originally planned for. Maybe you can work around it by storing ten different types of hashes, but it still isn’t really future-proof. You certainly aren’t protected against requests you could never foresee (Can we auth IMAP users against this forum user database?).

However, if you’re storing the password in cleartext, the answer becomes “So what? Can-do, boss!”. You can generate whatever sort of hash you need on the fly, you can use any password authentication scheme that you want. You can integrate with any password-based authentication scheme. Any. Not just the one you’re using today, or tomorrow, but the one you’ll be using five years from now. No matter how it passes over the wire, you can use it.

I’ve simplified this quite a bit, and there are a bajillion other ways to work around it - but nothing that is as compatible or usable as just storing the passwords in cleartext.

If you do want to work around it… Be inconvenienced! Some options might be:

• Make a stand and decide what protocols you support
• Don’t use just passwords, use two-factor authentication (passwords plus tokens, SMS codes, biometrics, etc)
• Accept the cost of forcing the user to visit the “change password” page to generate new hash formats when needed

Even as a user, you have a great option for keeping your own security:

• Use unique passwords for every account, so a compromised password can only affect the one account

It’s universally sound advice, but often ignored.

Remember finally that we (as developers and sysadmins) can make systems that are incredibly secure - just look at banks. It’s just inconvenient. Technical security, DMZs, firewalls, physical security policies, segregated backups, employee access policies. All that work! But it can be done.