Monthly Archives: January 2014

Password Sins of Omission — Will They Ever Learn?

“Where have all the passwords gone, long time passing?
Where have all the passwords gone, long time ago?
Where have all the passwords gone?
bad admins stole them everyone.
Oh, when will they ever learn?
Oh, when will they ever learn?”

(With apologies to Peter, Paul, and Mary)

It’s been quite a while but yesterday it happened again: after I had registered with a new electricity provider I was sent an email showing my password — right next to the words “Your Password”. There was also a link that I was supposed to click to verify my personal data, including name, address, date of birth and a lot more things that I certainly don’t want share with the world.

What amazes me most about this incident is that even today some companies are completely oblivious to how easy it is to automatically scan emails for keywords on their way from sender to receiver.

But even if the probability of someone sending around your credentials in plaintext is a lot lower today that ten years ago, the chances of being faced with poor password systems are still quite high. Here is my personal list of the grossest password-related blunders.

1. Storing user passwords. This is probably the greatest of all password sins, especially since it may spawn many other password-related follies. Don’t store passwords, not even encrypted. Instead, salt the password with a random salt and then hash it with a strong hash function before you save it. This way, no rogue admin can run away with your users’ passwords and no crazy customer service team is able to send around mails disclosing credentials.

2. Gratuitously limiting the password character set. I’ve come across password systems that only accept numbers (i. e. PINs), others only a mix of characters and numbers, some would accept special characters like %, &, and ? but not the dollar sign. I don’t see any reason why it’s not possible to use the whole unicode character set; at the very least, all printable ASCII characters should be considered valid. If I wanted to attack a site the very first thing I would do would be to set up an account and find out about their password character limitations in order to prune my search space.

3. Gratuitously limiting the password length. Some folks don’t seem to realize that with passwords, size matters: longer is stronger. An easy-to-type passphrase like “theluckgreensunsdontkiss” is much more secure than the complex, ugly, it’s-so-hard-to-remember-that-I-need-to-write-it-down “B!A7n4$”. While there is good reason to set a limit on the lower bound (I personally would require a minimum of eight characters) it is outright dangerous (read: stupid) to place an upper bound on the length. Be careful: If a site demands a password length of 6 to 8 characters, it is a clear sign that they take security lightheartedly. Maybe they even store your passwords and shorter passwords consume less space on server hard disks. Yikes!

4. Not telling users about limitations. Limiting the password length and character set is by itself a horrible practice, only made worse by not telling users what the limits are beforehand. It is quite annoying if you attempt to set a new password only to be rejected with an error message saying that your password is not in line with the password policy. This has happened to me many times and in one case there was a link to the policy that was broken.

5. No “show password” option. I vividly remember the day when I had to choose a password for a smartcard-based access system at a company I worked for. At the company’s registration office was a terminal that asked me to select a new password for my card. Since there were quite some (gratuitous) limitations (at least one number, a single capital letter, no number at the beginning, no underscore, just to name a few, and they were not displayed beforehand, of course), I had to try several times making minor variations to my favorite password until it was finally accepted. Later, when I had to use it for the first time, I couldn’t remember it anymore. I’m not sure, but I guess that if I had been able to see my weird password in plaintext after I set it, my chances of remembering it would have greatly increased. Normally, I know if somebody is staring at my screen (and this is rarely the case), so why not add a “show password” check box that I can tick? This would also help me in cases where caps lock was on or when I inadvertently switched to a foreign keyboard layout.

6. Setting constraints on the login name. Why does the login have to be an email address (which an attacker is likely to know or which might change in the future), or a number, or an eight character word in all uppercase? One of my web hosters forces me to sign in with my 12 digit customer ID that they assigned to me years ago; I always have to look it up and I always curse the web hoster. Users should have absolute freedom regarding their choice of login name — not only when they create the account; also at any point later in time.

7. Not encrypting passwords before sending them to the server. There are still some sites (and email providers) out there that ask for your credentials without establishing a secure channel first. What that means is that your login name and password are transferred in plaintext to the server and every random wiretapper is able to use it to place adverts to all kinds of shady products in your name. I don’t know how many bloggers are out there using WordPress, but it must be hundreds of thousands; and almost all of them login through a login page that doesn’t use any form of encryption. Even if the NSA is able to read your SSL-protected traffic anyway, it doesn’t mean that you want everybody else to read it, too.

8. Not (or wrongly) using a brute-force attack countermeasure. To prevent brute force attacks a good password system should track the number of failed login attempts. My bank does this but in a rather stupid way: after three unsuccessful tries, your account will be locked and you have to personally go to your local branch office to request a password reset. My suggestion: from three unsuccessful attempts on, have the user wait 10 minutes for every further attempt; additionally present a Captcha to defend against automated denial-of-service attacks.

So here you have it and this is just my personal tip of the iceberg. In order to get real security, password systems need to be both: secure from a technical point of view and user-friendly; at least, they shouldn’t haphazardly limit freedom. The best password policy is worthless (actually dangerous) if it requires users to invent next-to-impossible-to-remember passwords that will end up written down on sticky notes.

Since there are so many sites out there that carelessly deal with passwords and personal user data, I think it is a about time for a law that requires companies to follow certain minimum standards. We just can’t rely on good will and common sense. We have done this for quite some time now and it demonstrably hasn’t work out.