Archive for the ‘Policy’ Category

Your Password Policy Tells Me That You Don’t Understand Security

Monday, March 22nd, 2010

How many times have you tried to create a password and discovered that it was too secure for the site?

“Please enter a password consisting of letters and numbers.” What?! This is 2010; there’s no reason any software out there shouldn’t support quotes, backslashes, exclamation points, or even kanji characters in a password. A site that fails to support at least all the printable characters on a modern keyboard is saying something very, very scary about their backend software: “We don’t know how it will react.” Think about that. The developers are so unsure about the quality of the implementation of this standard, well-trodden area of code that they have to have their customers help to make sure it doesn’t break.

Do you really want to do business with a company that isn’t sure it can handle textual passwords? This problem isn’t limited to podunk websites; bank and brokerage sites are implicated particularly frequently in this.

So, next time this happens to you, don’t just click away or grumble and pick a weaker password; send a message to customer service, tell them it’s a problem, and send this article.

If you are a website affected by this:

First of all, thanks for reading. Whether you’re with PR or Engineering, the fact that you’re actually looking into a complaint puts you head and shoulders above a lot of sites.

Here is the question you should ask internally: “Is this a policy decision or a technical one?

If it’s a policy decision, you might be okay. Some organizations decide that special characters are too much for their users to handle: perhaps they result in too much customer support work doing password resets. If that’s the case, please take the time to look at the numbers, gauge your current customer base, and revisit that decision. The typical computer user has matured a lot in the last 5 years and with this change you can easily upgrade your users’ security (and confidence).

If it’s a technical decision, it’s time to start worrying. The user registration and login process is the most clear-cut example of security related code in any system. That entire code path, from the front end GUI to the back end database should have been thoroughly checked, tested, and made absolutely bulletproof. If there’s any doubt in anyone’s mind that the code on this path doesn’t do exactly what it should, that calls the entire rest of the development process into question. The key issue here is input validation, sanitization, and proper practice in isolating code (how your software makes decisions) from data (what it bases those decisions on). If this is done correctly, then there is no technical reason that special characters (indeed, any characters!) cannot be used in passwords. If it’s not done correctly, then the software is vulnerable to a whole class of potent attacks. Specifics of those attacks have been well covered elsewhere but the takeaway needs to be that this single detail may indicate much deeper problems. Looking hard at this issue now may save a great deal of pain and expense later.

Be aware that it might actually be a technical problem even if it’s also codified in policy. This is the most insidious case. What started as a technical limitation “way back when” got papered over with user documentation, and a well-intentioned inquiry gets nowhere. Make sure you push for an answer. If you’re a non-technical person trying to get a clear answer, ask what happens if international users try to use non-English characters in their username or password (Internationalization and Unicode support raise some of the same issues of character sets and separation of code and data). If it wouldn’t work, you’ve got an opportunity to kill a security bird and an internationalization bird with one stone by addressing this issue

Getting Help:

The Open Web Application Security (OWASP) project is a phenomenal resource for anyone wanting to get serious about security. Check out the OWASP Top 10 for a quick view of the kinds of vulnerabilities that exist in software, and what practices fix them (a short overview video; poor sound, good explanation).

Wall Of Shame:

(This is a starter collection based on polling a few friends, I’m sure there are hundreds more. Leave a comment if you have others, or if any of these have fixed it)

Capital One
Aetna
GoDaddy
Fidelity
Smith Barney
Verizon
Digg
StumbleUpon
Mvelopes.com
Wells Fargo (toLowerCase()?)
Progressive.com (Only special chars are @.-_)
GoGo Inflight Wifi
ADP.com