They probably hired the same security consultant as my bank, which requires your online password to be exactly six characters long. My hypothesis is that this is a technical limitation due to the password being stored as a char(6) in their database.
Same goes for Virgin Mobile (at least here in Australia), which ALSO requires you to only use numbers. Last week they forced me to change my password due to an "important change" - ascending or descending numbers were not allowed anymore. I guess they had a look at their plain text password database and realized that 99% of their users used 123456.
Purely a guess but I think they only allow for numbers because it's a phone company. If they intend for people to enter their password/pin on their mobile phone then limiting it to only digits that you can type from any phone is understandable. Now I'm not saying it's a good idea but at least there is some sense to it.
In no particular order my usual gripes with passwords and auth in general are:
* Disabling clipboard copy/paste (because now I can't use my password manager)
* Length limitations (anything less than 32 characters is a a limitation)
* Requiring punctuation or "special characters" (they're annoying and don't add real security ... just use a longer password)
* Lack of two-factor (preferably TOTP)
The password limit is really the scariest one. Short passwords are much easier to crack. Also, I have a sinking feeling that every site that says a password must be a specific max length is storing it in plaintext. Otherwise why the heck would it matter what the length is?
Huh. I never actually did the math before, but: there's 32 symbols on my (US) keyboard. Upper+lower+number gives a baseline 62 characters. This gives us a password space for brute force attacks of
10 char alphanum: 62^10, or 8.4e17
10 char alnumsym: 94^10, or 5.4e19
11 char alphanum: 62^11, or 5.2e19
One extra character instead of needing to type symbols into my phone, with nearly identical complexity? Sounds good to me.
I have Virgin Mobile in the US (it's one of the cheapest options with good quality phones), and it seems the same. It made me set a 6-digit PIN as my password, and my phone number is my username. Here are the requirements listed on their website:
Your Account PIN must be:
-6 numbers (no letters or special characters)
-no more than 3 identical numbers in a row (222)
-no more than 3 sequential numbers (such as 234)
If I did the math right, that's approximately 900,000 possible passwords, which is obviously really low
Is rate limiting by IP the best way to handle something like this (other than the obvious, allowing better passwords)? You could obviously rate limit by account, but then you make it easy for anyone to lock anyone else out of their account. And obviously rate limiting by cookies as mentioned is awful.
This is funny because these restrictions reduce the total number of possibilities. I get that the idea was to stop commonly used passwords, but that's what they should have done - disallowed the top N common ones.
No, it could have just been random. They've reduced their keyspace massively by doing that. Six characters, all numbers, no ascending or descending. 123849 is invalid as an example, as is 954391.
Massively? For every 3 digits you look at, they're only blocking about 26 out of 1000 possible values. Factor in that there are 4 starting points to apply the restriction to, and you get roughly 10% of passwords being blocked. That's only a sixth of a bit of entropy being lost. Barely anything.
so 741963 would pass? Not sure how that rule your stated actually functions, I am probably over thinking it.
I am curious what simple pattern people will adapt to once you eliminate simple sequences. It has got to be predictable, as in someone could put math behind it.
Any run of three characters in sequence, forward or reverse, is marked as invalid. 123 876 432 would all mark the whole password as invalid, even if they only take up half the string. Yours would pass though, yes.
His is two vertical runs along the keypad. The forbidden ones are horizontal runs. That's why it's stupid. Any modeling of passwords humans would generate for use on a keypad should forbid 741 by the same logic that forbids 123.
My guess (with nothing to back it up) is people will start moving into paterns of 963 852 741 or the reverse since they're easy to type on the numpad without really remembering the values.
edit: On second look, that's exactly what you did in your example.
6 characters for a bank password?! Get a better bank!
It's unbelievable how bad the password policies of some banks are. Mine doesn't allow special characters, for example. Fortunately it does allow longer passwords at least.
That's nothing, mine's a 5 digit pin code which they only validate 3 of in a random order (to annoy keyloggers, I assume) plus the last 4 digits of my phone number.
Edit: This feels like the scene where Mel Gibson and Rene Russo compare scars in Lethal Weapon 3.
Bingo. I wonder what their brute force protection is like, but I'm not going to go pentesting the login of a company I'm in the same legal jurisdiction as.
Yeah, similarly, Lloyds/HBOS in the UK do allow you to have a master password but you also need to fill out a "memorable information" where you select 3 random characters from a second password. But you don't type them, you select them from a drop down. I can see how this would annoy the most basic of keyloggers but it is also a UX disaster and not suitable for decent loggers. Pisses me off.
My bank not only allows a maximum of 6 characters, but it truncates all characters beyond 6 when processing the login form. If my password was "passwd", they would accept "passwdjdodw89wawlks".
My bank secretly truncates your password to the first 12 characters. The login form processes all characters. I found this out because I couldn't login after having "successfully" set my password to 32 random characters. Luckily customer support was able to confirm the first 12 characters of the password over the phone.
At least you have to enter the code in a virtual numpad that is randomized after each connection on their webpage.
I guess they settled for this measure so it does not annoy their less "tech-savvy" customers. I am baffled to see banks working with such low security practices in general ("admin"-like access on your bank accounts by any employee, checking money transfers AFTER executing it,...).
One bank that I'm not going to identify is particularly scary. Predictable account number (sequential, I think) + 4 digit PIN. Even if they lock individual accounts after X retries, nothing prevents a well-distributed botnet from gaining access to an account (on average) every 10,000 attempts.
There was a recent post analyzing the distribution of 4 digit PINs, and using that I think it was something like 20 guesses would give you a 10% chance of access.
Financial company I use apparently shares the same password between their web site and their automated phone system. So in addition to a max length of 10 or 12, you can't use anything non-alphanumeric since you wouldn't be able to enter it with a phone keypad.
Also rules out stored a hashed password, too. Terrible idea all around. (Edit: ok, I guess they could convert the PW to the phone key version when initially setting the PW, and then store both the hashed text PW and hashed phone key PW. So not "rules out". I just doubt they do it.)
Even if they do, acquiring both of these hashes vastly helps with brute-forcing: you first break the phone key password and then check only the alphanumeric passwords that match it against the alphanumeric password's hash.
> My hypothesis is that this is a technical limitation due to the password being stored as a char(6) in their database.
and legacy security policies/requirements that have not undergone any update.
I've worked on a project that touched banking passwords in the past and in a push for modern password requirements (which was met....somewhere in the middle), the response was that since the number of attempts was so restricted (and claims about whatever security/fraud engine they were using), the risk caused by the restrictive passwords were essentially negated.
From a security perspective, how true is this? I'm genuinely looking to be educated. It did seem like a reasonable measure to prevent a bruteforce attack, but I'm not sure if I'm missing anything
Sure, it's secure from a front-door perspective. But if say, a future unpatched software vulnerability leads to the password hashes being leaked (a when, not an if) the 6 letter password hashes are going to be mighty easy to crack.
Actually, having weird password requirements might make them, on average, more secure.
Why? Because the passwords will be different.
The average person uses the same password over many sites. The chances of one of those sites being hacked/rogue is 100x higher than the bank getting hit. Weird requirements = different password = more secure.
A common way of expressing what Afforess said is that simple passwords with effective rate limiting offer "brittle" security. As long as everything works perfectly, it's safe. However, there are many failure modes that rapidly degrade to trivially having access to all accounts. One would prefer to have defense in depth, such that failure of one part of the system would yield a system in which it's easier, but not trivial, for an attacker to access accounts.
Using a modern Key Derivation Function (KDF) such a Scrypt along with allowing more complex passwords would in many cases prevent attackers from accessing those accounts that used more complex passwords (or force the attackers to change the passwords on the accounts, risking discovery when the owners next try to log in). Enforcing minimum password complexity would dramatically increase the percentage of accounts that couldn't be bruit forced if hashes were stolen.
Hopefully the answers to security questions aren't kept in the same database as the password hashes, since they're nearly password equivalent. Even if the security question answers are hashed, 99.9% of the answers can be easily bruit forced. I grew up on g1SUIt2FJr1IHI Street and my first grade teacher was Mrs. IvwiYZ4Oar9uZg. Last year my dog was named AuiwVvMSPNTWbgy and this year I renamed him to dBuSHCTJDuSdAUu, but few people are so lucky. Also, when calling up my bank for help, it sure sounds like the phone operator can read my secret question answers off of the screen. In any case, an attacker takes some risk of discovery by resetting someone's password and hopefully banks all watch for spikes in rate of password resets, but secret question answers are nearly password-equivalent and seem to almost always be stored in plain text. The secret questions answers are the keys to the kingdom and the amount of code that has access to them needs to really be minimized and audited extremely well.
I would be very interested to hear a first-hand account from the developer who gets the requirements and has to actually build in these types of password restrictions. Did you object? Does anyone recognize how absurd it is?
Better than idiotic websites that enforce their character length limit on the client, but not on all pages on the client. So you can change your password to 123456789, but the login page will truncate it to 12345678
Strange. I tried just this morning before posting but I will update my password and try again.
edit: after updating my password it's now case sensitive, and allows special chars. As the sibling comment suggests, it looks like they have two different authentication routes and updating your password moves you onto the newer one.
I tried it with a new password today. The requirements were between 8 an 32 characters and some special characters allowed.
I just tried with all lower case letters and it rejected it. Prior to changing my password however, I experienced everything you described. They must have 2 systems and setting a new password must switch you to the new system. Can't fathom why they don't just mandate everyone changing their passwords.
I didn't know they changed their policy, so thanks :). Their old policy stripped out capital letters too which made it even less secure. Sadly it still doesn't allow all special characters, but it's a start.
My bank enforces a six character limit and the passwords aren't even case sensitive. But, brace yourself to feel safe - they make me answer a security question (in this case, "What high school did you go to?"
They made a (record) four billion dollar profit last year, so this strikes me as security designed by someone with an MBA and a spreadsheet. I'd be upset, but, I've been stupid enough to keep doing business with them...
I believe this is to allow alternate inputs of data, like "fill in the 2nd, 5th and 6th character" or special keyboards in ATMs, like "Press the arrow that contains the 1st letter of your password"
Very likely to be a legacy back-end system. Doesn't excuse it at all, but that's one I've seen limit banking systems in the past either in password length, complexity or case sensitivity (I've seen some systems automatically upcase passwords without telling you 'cause the back-end is case insensitive)
That could well be it. My bank enforces similar short passwords, but they're not such a big security risk since they lock the account after three mistakes, and require you to visit a branch in person to reactivate it.
I guess that means they're wide open to denial of service attacks, but that's another story.
I don't buy that as an explanation for ridiculous password limitations.
It is true that mainframe timesharing systems often had password requirements that are considered weak by today's standards. However, there is no reason for bank customers to even have accounts on the mainframe. Bank customer accounts have nothing to do with mainframe user accounts.
There is no good reason for any mainframe password restrictions to leak into the public facing web front end. To the mainframe, the web password should just be a data field in a database [1], and mainframe databases can easily handle data fields of sufficient length to support modern password best practices.
[1] Or rather, the output of hashing (with something like bcrypt or better) is just a data field in a database.
