| Subcribe via RSS

Rant: On Website Passwords

February 27th, 2014 Posted in Rants, Security

This morning, my email included a now-familiar tune: A site that I occasionally visit may have been penetrated, so the company was informing the registered users that they needed to reset their passwords. Logging in would take you immediately to a page that let you request a link for password reset. Nothing new, and not that big of a deal. Like I said, it’s been happening quite a bit lately.

But then when I entered a new password, the form comes back immediately, with a message in red that is also becoming all-too-familiar: My password contained characters other than letters and digits. That is not allowed. Please choose another password.

Are you freakin’ kidding me? This is 2014, not 1993. Why in the world does your system limit passwords to just the [A-Za-z0-9] character range? What database, what content-management package are you using, that having a “!” or “$” in the password would break the application? This is just ridiculous. And surely you aren’t storing these passwords as plain-text, I hope? I recently read an excellent article on how one should store passwords in databases, using a combination of salting and one-way hashing functions. Unfortunately I’ve lost the link or I’d include it here. But the point is, you aren’t storing the passwords as plaintext, you shouldn’t be comparing them as plaintext, so why should you care what characters are in the passwords? And then, just to put icing on the cake, once I had selected a new (weak) password they emailed it back to me as part of the confirmation message.

They emailed it to me. In the clear. Not encrypted. They are not the only ones who have done that, either.

I use KeyPassX as a password store. I like it because it is cross-platform; I have it on my MacBook, on my Linux desktop machines, and I have apps that are compatible with the key-store that run on my Android phone and my iPad. All of the installations can configure the location of the key-store, so I have them all pointing to the file on my Dropbox account, thus keeping my passwords in sync across all devices. (Yes, Dropbox is not 100% secure, but the encryption on the key-store file is strong so I’m not worried about someone getting it.) When I looked at the list of sites and passwords this morning, as I was updating the entry for this site, I could tell by looking at the passwords which sites do or do not have this silly restriction on password characters. Among the offenders are two telecoms, a health insurance provider and no fewer than three financial institutions. And these are just the ones that I personally use. I would really have expected more from the financial places, because they have so much more on the line.

Look, I write software for a living, even if I don’t specialize in security. Characters are characters… your software doesn’t view “$” any differently than “Z“, unless the software is doing something horribly badly. Unless your stuff is written amazingly poorly, you can do better on the password front. And if it is written that poorly, consider finding a new vendor… you aren’t doing yourselves any favors with what you currently have.

2 Responses to “Rant: On Website Passwords”

  1. AshleyNo Gravatar Says:

    Two years ago I updated the software of a product I work on to allow any characters in the UTF-8 range for passwords and upped the maximum limit from 12 or whatever it was to the full legacy DB field’s 255. This is a product with international customers.

    A year later another dev in the group rewrote the password handling to do exactly what you describe; ASCII, letters, numbers, no spaces, limited subset of punctuation, max of 16 characters. I guess I’m just lucky the dev didn’t undo the Crypt::Eksblowfish::Bcrypt hashing I added. :P

  2. VenTatsuNo Gravatar Says:

    A good starting place for password storage practices is https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

    There is one catch with ‘characters are characters’, if you allow any character value > 127 then you need to deal with encodings. You could assume Latin 1 and be ok, unless you really got UTF-8. Then the password entry in one OS and Browser could result in a different byte stream from another OS and/or Browser. So check if the browser sent UTF-8, and convert to a normal form, then encode before hashing.

Leave a Reply