Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Password security for boneheads

Paul Venezia | Dec. 9, 2009
Would you trust a random person with your passwords? You may well be doing that every day at supposedly secure sites.
Take this example, copied from a financial services company customer portal:-

The password may not contain any of the following characters: ", ~,!, @, #, $, %, ^, &, *, (,), +, =, \, |, {, }, [,], <, >, ?, blank or tab.

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 monthsand 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 databaseone 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 needs 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 listingin 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 (see,-Other-Sensitive-Data.aspx?pg=5). (If you want to laugh nervously for a while, go check out the rest of The Daily WTF (at


1  2  Next Page 

Sign up for MIS Asia eNewsletters.