There’s no technical reason why a competently-programmed website can’t handle passwords of any length, containing virtually any combination of characters, however squiggly.
But that’s not the case on the website of insurance company Direct Line if you try to create an account.
They don’t want you to use anything other than ‘a’..’z’, ‘A’..’Z’, ‘0’..’9′. Furthermore, it’s tough luck if you want your password to be more than 10 characters.
That doesn’t sound like good security practice to me. That sounds like Direct Line’s programmers are either lazy or don’t know what they’re playing at.
Direct Line is far from the only company which is guilty of putting such daft restrictions on its customers. But that’s no excuse.
Hat-tip: Thanks to @LargeGrowlyBear for pointing out Direct Line’s lousy password requirements to me.
Found this article interesting? Follow Graham Cluley on Twitter or Mastodon to read more of the exclusive content we post.
11 comments on “Direct Line says your passwords should be alphanumeric and between 8-10 characters”
Do they make you select 3 characters from your password at login? I suspect they do and that they pre-compute the hashes of all the combinations. So limiting the password length reduces the amount of storage required.
Selecting 3 characters from 10 requires 120 computed hashes, if the upper bound was 16 characters then this rises to 560 and if they allowed 30 characters then that's 4060 hashes.
Even if they pre-compute (which would be a very naive implementation, not that the current one isn't – but see below), to give an example – DES – uses 14 characters (granted there is a character limitation of 8 last I remember, but I go further than this). But let's look at something else because DES is old and has its own issues (what doesn't, though?). Let's say sha512 (I'm actually only after length of the hash). It results in 129 characters (despite length of password given). Okay, and then if we use your higher limit – 4096. It would result in a small number, obviously.
But in any case, the regexp in their checks says the following:
Password length >=8 <= 10
Characters allowed [a-zA-Z0-9]
The first one is obvious what it means.
The second one means any character from 'a' – 'z', 'A' – 'Z' or '0' – '9'. And there isn't any check there that says you have to have a specific combination or a certain amount of each group.
It occurred to me… although the idea applies still, sha512 above refers to sha512sum, which is not the same when dealing with encryption. So while sha512sum is 129 characters, sha512 for encryption, is not (it is 86, not 129 less).
Thinking about this further (and I did before but don't think I put it to your idea of number of hashes (which is different from my point – length), the hash length is one thing. So is the number of hashes (your point). I still don't think 4096 hashes is all that much though. But you also must keep in mind that that password length does not change the hash itself (so I'm not sure how it would save space). For UNIX passwords (using 3DES) it is 13 characters, with the first two being the salt. Of course, 3DES is a terrible choice but I am sure there are systems out there that still use it.
Although I hear what you say, what really gets my goat is when a website gives no clue as to that's acceptable in a password so I go with an upper case/lowercase/number/symbol combination only for the site to tell me that it's not acceptable and STILL gives no clue as to the characters that are acceptable.
Site like that tend to see me going elsewhere
How about a site that lets you create a 15 character password but when you actually try to use the password to login, the login form will not accept 15 characters. That has happened to me. I find programmers today are not necessarily lazy, just young and inexperienced.
This is very similar to what 53 does. They are a bank and have some pretty severe limitations on their password specs. Boggles the mind.
Fairly sure Virgin Media's password policy for online account services is close to this – perhaps even worse. I am not a customer per se but I seem to recall helping a friend recently trying to reset their password.
While I will elaborate, I'll still say "don't even get me started on this issue… I have stories here, too, as far as things I've seen (but not going to elaborate.. if I shame the company I will do it elsewhere with more details and more thought put in to it)". This issue is actually absurd (that it still exists). Others will allow non-alphanumerical characters but still limit WHICH characters they are.
Let's be honest here: in the mid 90s (you know, we had 16 and if lucky 32-bit computers! they were really powerful compared to today.) it was trivial to succeed in taking a password file and running a dictionary attack on it. This was with passwords with non-alphanumerical characters allowed. If that's the case then, what is it now? Answer: scary.
Compare the 16 bit computer (and they were fast unless lucky enough to have 32 bit… which were a little bit faster) single core CPU to my 64 bit CPU with 4 physical cores, 4 virtual cores at a clock speed (not counting Intel turbo boost which does indeed apply here) at 4.0Ghz each. Then there is more CPU cache, newer technology, the fact RAM is in its third generation (actually I seem to remember seeing that DDR4 is now out), higher capacity (and generation implies better timing and other stats). I'm sure the 8-32 bit computers of old were so much more powerful: SATA didn't exist, SCSI was still expensive (funny thing is it is still this way) and still problematic but faster than IDE (IDE, what's that?), 5.25" floppy disks (maybe 3.5" too… they had a lot of storage space too – 1.44MB was huge after all!), ~16MB RAM (maybe!). Hard drives were huge too! We were lucky to have 2GB but that was barely starting (remember < 1GB ? And remember how expensive they were when they came out and frankly any hard drive at that time ?) and those were really cheap too (depending on definition of 'cheap'!)… 56Kbps was fast for home Internet access and some (like me) had much slower. ISDN was really fast too (hard to imagine)! Right ? Well I admit I have fond memories of some of it but clearly if dictionary attacks were that easy then, with arguably smaller dictionary files (in fact the issue was also: do you have enough disk space ?), they are far easier now. The only difference (but not always applicable): better encryption standards. But that means practically nothing as long as you can do exactly as authentication checks do. [a-zA-Z0-9] is an extremely poor limitation.
I should be able to use all the characters sets that KeePass provides…
Microsoft Research puts the absolute maximum number of guesses a password needs to be able to withstand during an *online* attack at about 1,000,000. An 8 character passwords with 62 possible characters in each position has a 1 in ~220,000,000,000,000 chance of being guessed at random.
The chances are that an online attack would have far fewer than 1,000,000 guesses. 1,000,000 guesses on even *one* user account, never mind all of them, in any kind of sensible time period is a massive, obvious and expensive traffic spike. If you throw in typical rate limiting, say a lock out of an hour after 3 failed attempts, the attacker is chugging along at 2,000 guesses per user per month.
Where you need a strong password is in the much, much more difficult scenario of an attacker breaks in and gets the password database so they can crack it on their own super-duper hardware. Again, according to Microsoft Research, at this point you want a password that can withstand upwards of 10^14 guesses.
The password 'search space' for these 8 character passwords is ~220,000,000,000,000 possible passwords, which puts you above that threshold. If add the extra two characters and go with a 10 character password it's ~850,000,000,000,000,000.
The attacker also has a limited window – the passwords are only worth cracking until the admins reset them – and suffers massively diminishing returns, eventually the haystack is so much bigger than the needle that it's not worth it.
I think the password policy here is not optimal (why not allow a 25 character password full of wackies?) but it's not unsafe.
What really matters here is choice of password.
Brute forcing is the last resort, after patterns and dictionaries, so use a random password. If you're falling to a dictionary attack it's not the bank or the password policy that are at fault.
You are very wrong indeed: the password policy IS unsafe. And while it is true that brute forcing isn't always the most efficient way (IFF there are other better ways and only in certain conditions), it often is. I see you refer to online attack but the problem is this: you might want it to be an online attack because you have more chances of it being detected, but it often isn't. Just because you want it to be this way, or just because some suggest it should be a certain way, does not mean it will always be that way (not recognising this is not thinking like an attacker and if you can't do that then you won't detect as many things!). And stealing password files is nothing new. So while the maths MS does is relevant to online attacks, it is irrelevant in the end when you consider that online attacks are not the only kind (and I'm not even discussing physical attacks on the premise).
The thing is, what if by chance (and this is possible, is common, has been listed here before, multiple times, and will continue to happen), the server is forced to give up its password file? Exactly. The only thing that would save you (or certainly make it more difficult) is 2FA. But that's besides the point.
The other thing is, you suggest "Where you need a strong password is in the much, much more difficult scenario of an attacker breaks in and gets the password database so they can crack it on their own super-duper hardware."
Yes. Kind of. The problem is it doesn't take impressive hardware (especially with such a restricted password range as in the post). And it isn't all that more difficult. And it doesn't take one to break in to the network, either. I would argue it is easier in many cases (notwithstanding a struck of luck with a very poor system in place that makes it even worse for the victims). Example of old, one I can't say I'm completely innocent of (and frankly I think many more are guilty in some way, than would admit it: there was a patch that showed something like 'smile, you're on candid camera' on servers, that's how well known and used it was!): Apache 1.x.x phf bug that forced the server to show (cat) /etc/passwd in the days that shadowing was not the norm. 3DES was the de-facto standard and it allows how many characters? That's right: 8 (and yet more than the restrictions here, as I recall). The problem with your idea is that dictionary attacks is a form of brute forcing and it is still powerful, more so nowadays since computers are so much better. Combine that with taking a password file is still common and you see that it actually is important you have strong passwords (and not reused and more than 0-9A-Za-z allowed and yes more than 8-10 characters). As you suggest, choice of passwords is important but it is severely limited with 0-9A-Za-z as the restrictions.
So no, the password policy is not safe. It might hold up but it still isn't safe. Just like writing passwords down might hold up, it still is unsafe.