Monday, 23 January 2012

Password restrictions

I've been changing a lot of my passwords lately so that none are alike. In fact they're so ridiculously random and lengthy that I wouldn't stand a chance remembering them. I've a means of obtaining these passwords though in a method known to me using encryption which requires 2 very different types of key, so remembering them isn't necessary.

However, after going around trying to change my passwords, I've noticed that many places impose restrictions upon how long a password may be, and what characters you're allowed to use.

For example, with PayPal, they absolutely require you to have at least 8 characters, but for some reason, it must not be any more than 20 characters. Why limit it at 20? Surely they hash the password anyway?... don't they? eBay have an identical restriction.

And then came my bank (a Dutch bank which shall remain nameless). They also said that it must be at least 8 characters, but no more than 12. It must also contain at least one lower-case letter, one upper-case letter, one number and one non-alphabetic character. But then it also may not use a speech mark ("), equals (=), tilde (~), less-than (<) or greater-than (>). So this not only suggests they're not hashing the password, but there's also probably some risk posted by those additional characters, meaning they may not be sanitising their data. Normally if that were the case I'd expect characters like a back-tick (`), semi-colon (;) or single-quote (') to be prohibited, but for some reason those are allowed in this case. *shrug*

Google seems to be better at this, but still imposes an arbitrary limit. In this case they require a minimum of 8 characters, and allow up to 100 characters. Why 100? Does it matter? Thankfully they allow any character you like, including spaces and all types of punctuation you can think of. But in addition to this, I have 2-factor authentication enabled, so I require a 6-digit pin generated by my phone, so the risk of someone logging into my account is minimised. Although I guess this is all moot when it comes to Google's application-specific passwords. This is necessary if you use 2-factor authentication when you wish applications to access your account (such as an Email client), because those applications can't ask you for the 6-digit pin. So Google generates a password specifically for that application which can be revoked whenever you like. Here's an example of what its generated passwords look like:

qihi jnmd irjb ytis

They always show up as just lower-case letters, and the spaces don't matter. So really, if you have application-specific passwords enabled, the security on your Google Account is only as strong as those passwords, and obviously the more you have the lower the security. Still, it's extremely unlikely anyone could get into your account using brute-force trying to find a code, but it's a shame Google doesn't allow you to enter an application-specific password of your choice.

I also recently set up an account with Good Old Games (gog.com). The limit there was 32 characters. I tried using special characters in the password but found that it caused the form to show the password field as invalid, but wouldn't say why. I figured out they only allow upper-case and lower-case letters and numbers.

Amazon fare better than the rest so far. Any characters you want, up to 128 characters.

The best I've seen is SpiderOak. I gave it a totally random mix of every type of character and a password 1024 characters long. It was fine with this. I don't know how many more characters it will take, but surely that should be enough.

So SpiderOak is the most secure out of this list. SpiderOak also can't recover your password because they don't store it. Apparently it's only used to decrypt your user data, which they can't access. In fact they boast a zero-knowledge policy, meaning they don't know your password or anything that you're storing, not even including file names.

On the opposite end is the Dutch bank who shall remain nameless. You'd expect a bank to have higher requirements than most, but it seems not. 8-12 characters? And some characters excluded? What are they playing at? They don't even offer 2-factor authentication. It's just username and password (no, not even account details).

So, anyone know why these companies place such restrictions on passwords? Does it present a denial-of-service avenue? Do they not hash it in case they want to provide the password to, say, the NSA? Any good reason?

6 comments:

Thanks for introducing me firstly to SpiderOak, and from there to the intriguing "YubiKey" - a 1-time pad that avoids the need for a screen or custom software by simply pretending to be a USB keyboard. I love devices that work like that. :)

As for passwords, excluding characters is pretty indefensible, and suggests they don't trust their infrastructure to escape strings correctly; mind you, a client recently added text to their website telling customers to avoid apostrophes in names, because our system handled them fine, but (ancient) remote systems tended to strip them out, so "it would cause confusion when retrieving booking records".

I suspect the length limits in a lot of cases are simply because software architects aren't used to setting things to be "unbounded", even when using modern systems that do not require data to be pre-dimensioned. [Here's looking at you, PostgreSQL "text" columns :)] It may even be that the data has to pass through systems which do need specified data lengths, although as you say, a password really shouldn't be travelling far through the stack before being encrypted.

I do remember successfully registering an address something like iwonderhowlongusernamescanbebeforeyourunoutoftypingspace@hotmail.com but then being unable to log in because the username got truncated somewhere during the authentication process. Microsoft were not amused by my support request / bug report pointing out that the registration process should not have allowed a username that could not be used to log in.

So I guess it would be worse if a registration form appeared to accept your 1024-character password, but then truncated it before encryption...

Actually, thinking about it, isn't there a risk that your nice long non-ASCII passwords will actually collide with a much shorter string once hashed? Your 1024-character password (plus salt) will be stored as, say, 32 bytes (if SHA-256), so much of your information/entropy will be effectively discarded. I'm no crypto expert though, so I may be missing something fundamental about that.

Yes, there's always a risk of collision I guess, and entering ridiculously-long passwords doesn't really make things any more secure than ones which could be classed as "quite long". There's no advantage in a 500-character password over 30 characters in most cases (SpiderOak probably being an exception). I'm just interested in the reasons behind the limitations they place. Narrowing the range of passwords lengths makes things more awkward too. 8-12 characters is pretty dumb to me. Just as 20-24 would be too.

As for unintended password truncation, that sounds awful. Limits should always be tested, especially on something as high-profile as Hotmail.

While passwords offer some level of protection, I suspect most people tend to use the same one in several places. This means if one place is hacked (like user account names and passwords being leaked onto the internet), then there's a significantly higher chance that those credentials could be tested in other high-profile places (Amazon, Facebook, Twitter etc.). And I would expect some success with that strategy too. So I do think as more and more confidential and financial information makes its way onto the internet, better security measures need to be taken, especially when identity theft has occurred so many times.

Unfortunately I think passwords are here to stay as they're relatively quick to enter and people can remember them. Solutions like smart cards require extra hardware most people don't have, and 2-factor authentication can seem extreme to most cases. Of course threats of password leaks would be greatly lessened if companies learned to protect their networks with well-thought-out security, less liberal access to wherever their user credentials are stored and those credentials not to be stored in plain text. In fact I've seen a couples examples in the past where people think base64 is appropriate for password protection, for which I won't even comment on.