|
The other day on Facebook, one of my friends mentioned that today (i.e., that day) was a good day to update his passwords. But he then lamented that some web sites don’t allow you to create more than a 12-character password! He was incensed! Well, maybe not incensed but showed contempt for the fact these sites restricted password length.
As any good security person will tell you, the longer a password is the more secure it is (of course, the fewer failures a web site permits, the more resistant a website is to brute force attacks). But this annoys me about the industry—we preach that users need strong passwords (by recommending that they use different ones across all or most of their web logins that are impossibly long and oh, yeah—don’t write them down because we’re all so good at remembering long strings of random numbers and letters) and yet we can’t even co-ordinate our security policies.
I can see why some web sites would restrict the use of special characters—it’s to resist SQL injection attacks or similar. But aren’t there other ways to sanitize the input without restricting users’ abilities to keep themselves secure?
And what’s up with restricting the number of characters to less than 12? Is it to save on hard disk space? Seriously. If your capacity is in trouble because of hardware disk space, you’ve got other problems. If you are trying to reduce cross site scripting or SQL injection attacks, find another way to sanitize the input.
Before we continue to complain about the irresponsibility of users, the security industry needs to clean up its own act and stop making things so difficult for users to understand and use in real life. The security industry has to get smarter about the ways it transmits its messages. Make it easy for users to be secure so they have to earn the loss of their data.
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byVerisign
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byWhoisXML API
Restricting characters in input is completely the wrong way to go about it. Any half-decent database API has facilities for automatically quoting and un-quoting SQL strings. It’s a sad indictment on the industry as a whole that SQL injection attacks exist at all.
Usually it’s because someone, at some point in time, arbitrarily decided that the password field should be of type “char(n)” for some value of n. The person who designed the database schema—using the term “design” loosely, since actual deliberation is rare—probably wasn’t a security expert, and n characters was enough for his password.
A small portion of today’s quick and dirty hacks go on to be tomorrow’s core systems, along with their hard-to-fix-in-retrospect lack of security planning.