The standard method for interaction with computer applications has gone from being the command line to being the native GUI, to being the web form. We were awesome at verifying input when it came from the command line — that was simple. Then we were kind of ok verifying input in the native GUI, although quality varied a lot more.
Now we suck at verifying user input from web forms. The current state of code that verifies user input has both managed to take us back to the kindness of the command line when it comes to freedom of input and manages to check all the wrong kinds of things. Why is it so hard to write these checks? I suspect because people don’t really think much about them, and I bet there are more interesting things out there than to write user input verification.
These problems aren’t some beginner coder errors either — they’re rampant on even the biggest sites out there like paypal.
The most common field to get me snared is the phone number field. In 99% of all cases, the site assumes that all phone numbers in the entire world are formatted like US phone numbers. Not, as one could imagine, because I’m claiming to live in America — I clearly just told the site that I live in a European country. So anyway, inputting my actual phone number causes an “invalid phone number” error. Not that there is any mention whatsoever on the site about what the correct format of a phone number is (there are, in fact, even several ways of writing a US phone number).
This sets off a wildly unamusing guessing game of how to “convert” my phone number into a format the site will accept. This practice often costs the sites money as I end up giving up and going somewhere else, frustrated and unable to make a simple online purchase that didn’t really require that phone number anyway, did it?
Another highly amusing game is the one where web sites try to force users to choose “secure” passwords by enforcing the formats of passwords. “You must have at least 6 characters, with at least one letter and one number”. Sounds good, except in general these passwords are restricted to only contain letters and numbers. Hold on, isn’t it common wisdom to include at least one non-alphanumeric character in a secure password?
As such, out of my set of passwords, the only password which tends to pass most password verifications is my least secure one. The idea that you could fix a social problem through technology is somewhat funny anyway — “password1″ is not more secure than “password” in any way that really matters.
The same thing applies to the old trick of forcing your users to change passwords every month. This can have two potential outcomes — users append a counter to the end of their password, and increment it every time they are forced to switch, or they keep a post-it note taped to their monitor with their current password. Neither outcome is a net gain in terms of security.
Some sites even let the user set a password which is then considered invalid when the user tries to log in (ebay, for instance, has done this) — causing a prompt for a new password and much annoyance.
Parsing stuff is what computers are good at. So forcing me to input something in a strict format is always a loss. Either separate the fields and force me to select the individual parts of a date separately or actually use all that computing power at your disposal to do your user a favor. Telling me you have no idea what I mean by “2009-12-21″ because you expected “20091221” is annoying the user for no good reason, even if you told me to not include dashes.
If you find yourself in a situation where you need to verify input from the web, take an extra minute to consider how you could make things as convenient as possible for the user, which ones of your assumptions only hold true for the region you live in… and when you’re done, whatever you do make sure you tell the user exactly what the expected format is.