The beauty of numbers

Some things are pretty obvious after you think of them.

When a new user signs up on FormSpring or Ponyfish, a randomly generated password is emailed to them. It’s a fairly simple way to make sure that a valid email address is associated with an account. Both services also have a password reset function that generates a random password and emails it to the user. Pretty standard functionality — I think most web services I’ve seen have a similar workflow.

I occasionally have a user send support a message saying that their randomly generated password doesn’t work, even after regenerating the password several times. I know I’m not impervious to writing buggy code, but I think the password generation routine is fairly straightforward, and seems to work for 99.99% of users. Given the evidence, I have to suspect that the problem may lie with the user. However, it’s so Nick Burns to send a message back asking users if their caps lock is on. If someone from tech support asked me that, I’d go ballistic and do something really big, like write a blog entry (yeah, that’ll show them).

After responding to someone who had this problem in the most “it’s probably not your fault” way I could think of, it dawned on me — why not make the password a number? It’s been hammered into my head for so long that for security reasons you want to have a good combination of alphabetic and non-alphabetic characters. But for a temporary password, what’s the harm?

There are 218,340,105,584,896 possible 8 character passwords using numbers and uppercase and lowercase letters. There are only 100,000,000 possible 8 character passwords using numbers. Sure, I’d rather go with the former in cases when security is a major concern, but do I really think someone’s going to be able to effectively try 100 million combinations on a password from a login screen?

It seems pretty simple when thinking about it now that in regards to usability, sending someone a temporary password of 12345678 is a lot better than AbCdeF12.