Tuesday, June 27, 2006
I was trying to register on a web site this morning. It didn't like the password I had chosen. The site complained:
Password length must be at least 5, and it may not contain any spaces or non-printable characters
Well, my password was definitely more than five characters long. It did contain a space, however. Why is that so problemmatic? I cannot, for the life of me, fathom why there are so many programmers out there who refuse to allow people to enter good passwords for things. To make their own programming tasks easier, they arbitrarily restrict the character set of passwords to the easy characters (letters, numbers, and a few non-controversial puctuation characters). Characters that seem to be particularly challenging for these programmers to deal with include spaces and quotation marks of various sorts. Of course, exactly which characters are problemmatic differs from site to site depending on the laziness of the programmer and the peculiarities of the web site back-end.
Rather than coding up a routine to detect all these problemmatic characters, why not spend that time writing a routine to properly escape them whenever they cause problems?
To put some numbers around this, let's just consider random passwords for a minute. By my count, there are 95 printable characters in US-ASCII (non-control characters). Using a 5-character password, that gives approximately 7.74 billion combinations (= 955). If you eliminate space and anything "quote-like" (double quotes, apostrophe, and backquote), that's 91 characters, giving you 6.24 billion combinations, or a reduction of 19.3%. That's a significant reduction of the search space to break a password, all because a programmer was lazy.
"Aha!" I hear you cry. "Just add another character to your password and it's far stronger anyway. After all, 916 = 568 billion combinations." Yes, that's true, longer is definitely better. But it turns out that for the same password length, the percentage reduction in the search space increases as the length gets larger. Thus, at five characters, the reduction is 19.3%. At 10 characters, it's almost 35%.
So, please, if you're coding a login/registration system, do everybody a favor and just write some escape routines. Don't take the easy way out and throw out a large percentage of your security just because you're lazy.
You're confusing laziness with stupidity. It's lazy to call the database's provided escape function. It's stupidity to write your own function to filter input.
You have a sup tag closed with /sub, and it's confusing my feed aggregator. Would you care to fix it? :-)
I would not call the database escape function. Rather I'd base64-encode the password. Simple, secure, portable and future-proof. Specifically for lisp, calling the database escape function seems to be a lot of hassle with the interface-modules I am aware of, and base64-encoding is available in every mime-package.
You could add printable Unicode characters to the list and get a huge boost in password namespace. The problem is that you must then deal with string preparation (starting with normalization, mapping various characters, prohibiting others, dealing with query/storage/display storage distinctions w.r.t. private use codes, etc...). Throw in cryptographic protocols that use passwords and things get complex. Worse, the set of characters that can reliably be entered on all the UIs that your users can use can be pretty darn small (smaller than the set of printable US-ASCII characters).
Finally, you assume that shorter passwords from larger namespaces are easier to remember than longer passwords from smaller namespaces. Maybe, I don't know. But I do know that it's not trivial to expand the set of characters that users can use in their passwords.
Post a Comment
Links to this post: