You might think that, by now, most critical Web applications would have figured out password security. You know -- requiring strong passwords, not storing those passwords as plain text, that kind of thing. Unfortunately, you'd be wrong.
Take this example, copied from a financial services company customer portal:
The password may not contain any of the following characters: ", ~,!, @, #, $, %, ^, &, *, (,), +, =, \, |, {, }, [,], <, >, ?, blank or tab.
[ Are your organization's passwords strong enough? | InfoWorld's Roger Grimes shares more advice on managing passwords: "Prepare for the next password attack" | "Password size does matter" | "Getting a grip on better password hashes" ]
Now, blank and Tab are acceptable, but for the love of God, why can't I use special characters in my password? What possible security policy could forbid their use? Who decides this stuff?
But that's not all. This particular site also forces password changes every two months -- and new passwords cannot be the same as any of the past 10 passwords. That's nearly two years. Most people, unfortunately, use the same password on a variety of sites, so there's some basis in reality for this policy, but this particular site happens to be a read-only mortgage information site. I can log in and check my mortgage balance and whatnot, but I can't really do anything more damaging than pay my mortgage. Naturally, I log into the site only a few times a year, and every single time I have to change my password to a password that I wouldn't use for anything simply because it's weak. Then I either have to remember it, write it down, or save it my browser. More often than not, I have to go through the password recovery rigamarole.
More disturbing is the way password recovery works on some of these sites. At least half the time, when I get the (unencrypted) recovery e-mail, my password is right there in the message, in plain text. That means the site is storing all those passwords in plain text in a database -- one that's being backed up somewhere and is probably readable by a significant number of admins and possibly anyone who happens to snag a backup tape. It's a catastrophe waiting to happen.
Fixing these problems is extremely simple: Hash the passwords and compare the hashes. It's really pretty trivial. MD5 hashes can be cracked, so use something else. Do anything besides storing passwords in plain text. I'm amazed I even have to mention this! Maintaining a database of plain-text passwords is a massive liability; nobody needs to know that password other than the user. If it need to be recovered, create a random password, mail it to the user, and force him or her to change it on the next login. It's not rocket surgery.
I've also seen sites with simply hideous coding that actually embeds the plain-text password in the session or as a cookie. How on earth could somebody possibly think that was a good idea? When doing some Web work and troubleshooting a bug in some cookie interactions, I happened to catch one of my passwords in my browser's cookie listing -- in plain text and being sent to an unencrypted site with every request. I was mortified. But even that's somehow not as bad as embedding SQL queries in an href. (If you want to laugh nervously for a while, go check out the rest of The Daily WTF.)
The grizzled Unix veteran in me wants to think it wasn't always this way. Back in the day, the resources simply weren't available to write and run bad code -- everything had to be as clean an concise as possible. Nowadays, anyone who can type a semicolon can apparently code for supposedly highly secure financial Web sites. You're trusting your identity and possibly your bank account to that code every time you click the login button. No wonder identity theft is so simple.
This story, "Password security for boneheads," was originally published at InfoWorld.com. Follow the latest developments in security at InfoWorld.com.