Minority Opinions

Not everyone can be mainstream, after all.

Signs that you’re storing my password in plaintext

leave a comment »

I recently created an account with a major financial institution, which claimed to use the latest account protection technology. That made it all the more grating when it became patently obvious that they were going to store my password in plaintext, probably in a database field. Granted, there were a few measures to counteract phishing and hammering, but that doesn’t make me feel better about the fact that some employee somewhere has the ability to see my password.

I used to have two types of password: one relatively secure, and one completely insecure.  The first included a few special characters, and would be systematically changed for each place I needed it.  The second was emailed to me when I created an account somewhere, and happened to stick in my head; it rarely changes.  However, the sheer number of passwords I need, frequently with completely incompatible restrictions, combined with a growing fear that someone would figure out my simple pattern, drove me to store all my passwords in KeePassX, changing to new randomly generated passwords wherever possible.

That’s when I discovered just how well-founded that fear had been.

1. Length limits

If your system doesn’t allow 120-character passwords, I’m pretty sure it’s being stored in plain text somewhere.  A limit of less than 32 is just plain insulting, given how much more secure passphrases are than passwords.

If your system silently truncates my password, I’m absolutely certain it’s being stored in a length-limited database field.  On at least three separate systems, I’ve entered a long random password, and came back later to find that my password didn’t work.  After dropping characters from the end, sometimes one by one, I would eventually find the length that works.  32, 20, or even 16.

The worst part is that it’s all completely unnecessary.  Simply hashing the password will give you a result that can be stored in 64 characters or less, depending on your algorithm and encoding.  For extra security with no added storage requirements, use the HMAC algorithm with a random salt.  At that point, there’s no real reason to limit my password to anything less than a kilobyte, and that’s mostly for network transfer reasons.  Even 255 seems reasonable, if you want to be really restrictive.

2. Special character restrictions

If your system doesn’t allow me to use apostrophes, quotation marks, semicolons, colons, parens, slashes, pipes, or other ASCII punctuation marks, I’m going to assume that it’s being stored in plain text somewhere.  Such characters could break various flat file formats, and usually need to be escaped when stuffing them into SQL statements, but there’s no good reason for you to be doing that with my untreated password.

Similarly for spaces.  I don’t disagree with trimming whitespace from the ends of a password, or with disallowing newlines, tabs, and other control characters, but disallowing spaces in the middle of a password is a very bad sign.

Non-ASCII characters I’ll give you a pass on, until character set issues all get resolved, but I might sometime like to use a mixture of Greek and Korean letters, encoded as UTF-8.  At the very least, it would make it easier for you to go global; do you really think the Chinese want to use English passwords?

If your program weren’t so poorly designed, it would have the ability to escape any character that it might otherwise have trouble with.  At the very least, you could be using a hexadecimal encoding on it, though a base-64 encoding would generally be better.  Best of all, you could be running it through HMAC, which can handle any string except maybe one with null bytes, and encoding that result.

3. Password similarity restrictions

If your system complains that my new password is “too similar” to my current one, and you haven’t made me input both on the same form, then you’re definitely storing it in a recoverable form, which I’m going to treat like plaintext.  That goes double for comparing it to even older passwords.  It’s possible that the system uses my current password as a decoding key for the older ones, re-encoding them with the new password if successful, but I doubt that your programmers have really gone to such lengths.

If you complain about re-using an exact password, I’ll still be suspicious and annoyed, but it’s not nearly as sure a sign of a stupidly insecure system.

4. Emailing a password to me

If your password recovery system involves sending my current password to my email address, I’ll know for certain that you’ve stored it in plaintext, or at least in an easily decoded form.  Much, much better would be to email a link to a password change form, using an HMAC token to verify that the link came from that particular email.  For best results, don’t change my current password unless I fill out the form, to protect me from being too annoyed by having another user’s password recovery attempt hit my account.

Almost as bad is when you email me a new password, particularly one that I’ve chosen.  That turns my email into plaintext password database; if someone gains access to it, they have my credentials on your system.  If my password pattern is detectable from such emails, perhaps on every system.  Even if it’s a brand-new autogenerated password, why are you sending me a password instead of a single-use or limited-time link to create my own?

5. Displaying my password on the screen

I’ve had clients demand the ability to see passwords for users they’re in charge of.  In particular, for children who aren’t as likely to remember their own passwords.  That felt fishy to me, so I compromised: Any password randomly generated by the system, or set by a system administrator, would be visible to administrators, but any password created by the individual user would be hashed with a freshly randomized salt so that not even the DBA could identify it.  (The presence or absence of a salt in the database row also proved to be an effective way to signal whether the password was plaintext or hashed.)  That allows the users freedom to employ password schemes of any weakness without fear of getting accounts on other system cracked by an unscrupulous admin on ours.

I expect your system to show similar respect for my passwords.  Don’t ever show them on the screen, particularly over the web.  Not to me, not to anybody.  The only type of password you should ever show me is a randomly generated one; even then, a link to a new password form would be even better.

6. Sending my password to an external service

Sometimes there’s simply no getting around the requirement to store credentials for a third-party account.  Fortunately, I usually understand exactly what I’m getting into with such systems, so I tend not to get annoyed with them.  Nevertheless, there are a wide range of options here, some of which are much better than others.

If you can avoid it, don’t store my password unencrypted.  There’s probably some sort of keyring you can employ: a program that asks for a master password once, and sticks around in my desktop (or browser) session to provide credential storage to programs I launch.

Even better would be to avoid storing my password at all.  If your service is web-based, can you use OpenID instead?  If your service involves a desktop program that connects to the network, can it use SSH public keys?

7. Expiring my password every three months

Now we’re getting into less certain territory, but it’s related, and it annoys me, so I’ll list it anyway.

If you force me to change my password as soon as I log in, then it had better be because you sent me a single-use password in an email as part of the signup process.  If it’s because my perfectly good password has expired, then the amount I hate you will be inversely proportional to the length of time it has been since I last changed it.  Perhaps your system is being responsible with my passwords, but your actions display a severe lack of confidence in their security.  Even if your database doesn’t store my password in plaintext, I’m fairly certain that a significant number of your users store theirs in password managers and/or hand-written notes.

If, instead, password expiration forces me to submit a service ticket to have an actual human create a new password for me, the only reasonable explanation is that you’re relying on it to close the accounts of users who should no longer have access.  Even in that case, you have incurred my undying wrath.  If you have topped that off with the inability to change my password again for another 24 hours, and I ever gain the ability to freeze time, all traces of your program will suddenly cease to exist.


Written by eswald

9 Mar 2011 at 1:09 pm

Posted in Technology

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s