Jump to the millipedia homepage
millipedia

Bleeping passwords

Now I'm not one of these dads who embarrass their children by pretending to know all about up to date music; no, I embarrass my children by listening to old skool techno and waving my hands in the air.

So - when I went over to Bleep.com to stock up on some chewnz (yep that's right kids, that's what we used to call them) I was a little surprised that it wouldn't let me log in.

I'd set up my account just after the LinkedIn password leak the other week and had conscientiously chosen a nice long password. It was stored in my password manager though so I was pretty confident that I was putting it in correctly.

After failing to log on a few times on one machine I managed to get on using a remembered password in the browser I last used to access my account (yes, yes, I know I'm lecturing you about security and I'd saved my password). I thought I'd best update my password again so I definitely had the right details, so I went to change my details and pasted in a new nice long password. It was then that I noticed that the password fields looked like this:

Bleep password fields

 

... hang on... I've just hit ctrl-v twice but those password fields contain different numbers of characters.

A quick poke into the code shows that yep - the first field has a maxlength of 17 characters set, but the second has no limit:

<input name="password" id="password" tabindex="2" class="" size="40" minlength="6" maxlength="17" blank="true" type="password" >
<input name="repassword" id="repassword" tabindex="3" class="" data-equals="password" size="40" type="password">

The signup form has a maxlength of 17 characters on each input so when I signed up and pasted in my nice long 20 character number it only accepted the first 17 chars. Because the signup form has the same limit on both password fields I didn't notice it had truncated my password and so happily continued with my sign up and didn't have any problems until I tried to sign in again.

The good people at Bleep aren't the only ones to stumble up against this problem. The same thing happened to me previously when I was ordering memory from Crucial. Mind you, they sent out my password in an email so I noticed they'd truncated it ... which of course is not good news. That's for another post though I think.

There are a few reasons that a developer might limit the password length but none of them are great.

One obvious one is that the password needs to be stored in a database field and if you're trying to keep your database size nice and neat then you might limit the size of your password field to say 20 chars. But of course you don't keep passwords in plain text or obfuscated or indeed in any format that you can get at. If your product allows you to view your password once it's been entered then be suspicious.

Passwords should only be stored in a database using a one way hash - there's never any need to be able to work out what a password is - only that your user has given you the right one.

Once a password has been hashed then storing the hash in a database takes up the same space however long the original password was, so there's no probablem in deciding what size to make your database fields.

It is important that you use a decent length password in the first place - especially if your database full of hashed passwords has fallen into the wrong hands. Computers are really good at doing dull repetitive tasks like trying to crack passwords, and that's assuming that your password isn't already available in a rainbow table.

There's lots of information out there about why you need to chose long passwords. Steve Gibson's haystack project is a fun place to start or, of course, you can always rely on XKCD.

 

Copyright XKCD of course. Their alt text is funnier than this as well.

 

Jun 19, 2012