Hacker News Reader

Comment by fdej | Hacker News Reader

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.

View on HN

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.

Edit: Australia seems to be using the US system: http://www.bitdefender.com/security/hacking-virgin-mobile-us...

Given that they've requested you to change password to conform to the new rule, I believe you were within these 99%? ;)

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.

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.

Date of birth probably. Now half of their passwords has 19xx in the same position.

I'm of the opinion that everybody should be given public and private key at birth.

It's called name and social security number :)

But those are both public

Demons have name and secret name. They figured it out.

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.

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.

That sounds like a much better security fix than allowing the full range of alphanumeric characters + symbols.

Same goes for Virgin Mobile France.

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

Yeah, I wrote about this a few years ago and got a lot of press for it. They didn't really fix it, but at least they started rate limiting by IP address. https://kev.inburke.com/kevin/open-season-on-virgin-mobile-c...

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.

There's no great way to "handle" something like this besides modifying the protocol to be less vulnerable.

Phew. Dodged the bullet on forbidding vertical and diagonal strobes of the keypad.

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.

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.

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.

Sounds like AIB. If you use the app they don't even ask for the last 4 digits of your phone number.

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.

Well if you don't cross state lines, they're less likely to get the FBI involved...

It's an Irish bank, which means I won't be crossing any state lines ;)

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.

"This feels like the scene where Mel Gibson and Rene Russo compare scars in Lethal Weapon 3."

You might also refer to the scene from Jaws(1975) where Hooper and Quint compare scars: http://www.rowthree.com/2011/10/18/finite-focus-competitive-...

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.

Fun times were had by all!

My bank uses a 6 digits pin code...

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

How true is this? Bullshit.

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.

For a system that limits passwords to 6 letters, I bet they weren't hashing them to begin with. But maybe nchlswu fixed that.

How often do major US banks have their password tables leaked? When was the last time it happened?

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?

My bank (TD Canada) used to have this policy. Luckily it changed.

However, they didn't tell me (or anyone) so I've been telling everyone I know to update their password to be longer.

Thanks for the tip. I almost refused their online banking service because of the short password length.

TD's password is still HORRIBLE. It is case insensitive and ignores anything after the first 8 characters and doesn't allow special characters.

If my password is "aBc123De" I can log in by entering the password "ABC123DEFOOBARBAZ".

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

I just tested this, it is case sensitive and it doesn't ignore things after 8 characters.

I'm using TD Canada, not sure if they've maybe updated since you tried?

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.

Perhaps this[1] has something to do with it?

[1]: http://stackoverflow.com/questions/2179649/are-passwords-on-...

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.

Yup this appears to be it. I just changed my password and can now use a longer password with special chars (no spaces though).

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...

It's to the point where we have to invent fake identities for ourselves for authentication purposes.

I'm lucky my mother's maiden name is 32 characters, including caps, numbers and special characters.

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"

But yeah, it's stupid

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.

> stored as a char(6)

Try PIC X(6).

Or they have a web front end that goes over to an old mainframe.

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.

I agree but it wouldn't surprise me if they did it all wrong and were just passing credentials.

Reply on news.ycombinator.com