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.
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.
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.)
> 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
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 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.
Almost all big companies handle security on this kind of cargo-cult basis, because it's easier than finding someone who understands security and letting them overrule stupid ideas.
PCI compliance requires we change our login passwords every two months. This to me seems to just encourage users to create insecure passwords and sticky notes with them written down somewhere in/on their desk.
Put yourself in their shoes though. The people at the top don't really understand security, other than the vague "only the right people should have access to stuff" requirement.
I think the problem is that the people in charge of making decisions are gun-shy. Because of their inability to properly evaluate the security itself, it's also very difficult for them to properly evaluate people telling them what the security system should look like, and they've been burned by bad decisions in the past, so they take the "lalalala do nothing" approach and hope for the best. From their point of view, it's a perfectly reasonable approach to the problem.
maybe this loud PR thing will go up to the people in charge and stuff could be actually resolved at the root?
Or maybe it will just be forbidden to tweet about internal policies in the future for security reasons, NSA cover style.
So, this is just someone on the BritishGas twitter account. We do not know if that person is repeating accurately what they've been told or just making stuff up.
Assuming they asked the correct people in BG website accounts security, and those people said "it's to prevent brute force attacks" we do not know if that's the real reason they do it or if it's just what they say to people who ask.
What is really frustrating is that there is no possibility of getting this changed - allow people to paste their passwords and use rate limiting to catch brute forcing.
Having said that, some aspects of BG's computer system are horrific for customers so I don't doubt that they do stupid things for stupid reasons.
Thank you! I get amazed every time the internet freaks out because XYZ Company confirms "blah", when in reality, it's just a single service rep, who probably just wants to get you off of the phone.
As if blocking pasting actually stops brute force attachs... Can still just write a script that repeatedly makes those HTTP(S) requests. They accomplished nothing except annoy their more technically advanced users.
Do they think a brute force attack is done by someone copy-pasting in passwords?
Then they should clear the clipboard via JavaScript when submitting the login form, not prevent pasting of the password. Password managers are simply too much of a win to block.
Clearing the clipboard would be annoying for people who commonly copy a bunch of text out of a document, log in to their bank, and then paste the text somewhere else, but I suspect this is a rare workflow for most people.
I did work for a very security-minded HR outsourcing company on an html site to be used on a public kiosk and we also disabled paste via javascript for the same reason - to prevent a user from being able to paste in a previous user's password at the same terminal.
It always concerns me when big companies like this do weird things when it comes to passwords. Why do banks for instance have stupid password requirements; max lengths, disallowing certain characters, etc.
Surely if they are hashing the passwords in any form then it doesn't matter how long the password is or what characters it contains.
I understand perhaps the view is some people are not good at remembering passwords and so would forget a complicated password - but they are unlikely to use a long password or special characters if that's the case.
The last bank backend I worked around was composed of several interacting systems, written 30 or 40 years ago in COBOL, which ran batch jobs overnight and communicated with each other by writing files to disk. We were strongly encouraged to get the format of the file exactly right, or the batch job in question wouldn't run and nobody would be able to sort it out until morning. Passwords weren't involved but, if they had been, I am quite sure they would have been stored verbatim.
So, two problems: multiple interacting systems, which means you can't just fix one, you have to fix all of them; and lots of legacy code. Versus: there would certainly be quite a lot of pain to implement a new system, and the old one appears to be working.
> ... stupid password requirements; max lengths ...
> ... if they are hashing the passwords in any form then it doesn't matter how long the password is ...
Max lengths aren't inherently stupid. Presumably no one thinks 250MB password submissions should be handled, so you will be picking some number (possibly imposed on you by your stack).
Before laughing at how stupid this is, remember that your debit card is secured by a password that consists of exactly four decimal digits. I really wonder when this is finally going to change, but I hear some futuristic banks allow up to six digits already.
Well, it's not like my card is hooked up to the internet for everybody to try and log in.
PIN isn't particularly vulnerable to brute force anyway, as number of failed authorisation attempts is strictly limited to something like 3, and a fraudster has to risk capture by being physically present at each attempt or 'trying out' a stolen card, and having their face recorded on cameras.
I haven't seen any advantages for using 6-digit or larger "passwords" for that particular scenario. The largest practical security benefit seems to come from enforcing random PINs and not allowing to choose - since the banks that allow to choose are vulnerable to "dictionary attacks" of trying the user's birthday (obvious from other stuff in a stolen wallet) and stuff like 1234.
Now, checking "signature" instead of chip&pin, now that's an example of blind trust.
Cards are way different. They combine something you have (the card) with something you know (the PIN). After three false attempts to enter the PIN you have to unlock the card going a different route. In such a scenario, 4 digits are fine.
You can't lock accounts only protected by a password and accessible by anyone (via internet) this way as this would invite for Denial-of-Service attacks (locking your account with three failed attempts).
It's secured by a four digit password and self destruction after three consecutive invalid PIN entries. Which is plenty secure against brute force. Or is that just the way it works around here?
Mine is 10 digits. I thought the 4 digit limit was just a societal assumption? (I'm being serious, I thought it was (near) universally allowed to be longer, people just didn't bother.)
The standards allow for up to 12. Not that people always implement them properly, but that's what you're supposed to support if (like me at the moment) you make credit-card terminals.
To me this sounds like a crazy PCI Compliance related rule; and someone who doesn't understand anything about the PCI Compliance process or brute force hacking made the tweet.
When I ran a web-site with an e-commerce store that accepted credit cards; I was required to have PCI Compliance scans done.
One of the things they had me do was turn off the autocomplete on the password field with autocomplete="off". I have no idea how that makes things more secure.
A lot of the things they made me do in order to be PCI compliant made no sense to me. I think I spent a week trying to convince them that my "error" page which showed up when someone mistyped a URL was not a security risk and was not something I should remove.
I would guess that the single greatest hole in computer / network security comes from the terror regime of incompetently enforced “security”. Users WILL get their revenge by undermining such measures any way they can in order to re-establish some usability. Like the best camera is always the one you have with you, the best security is the one your users will actually support, and not feel forced to circumvent.
Call me a conspiracy nut but after reading all the accounts of banks and companies ridiculously reducing keyspace in weird ways (give me a good legacy-tech reason for [0]...) I'm starting to believe that they're doing it on purpose.
My bank has a password-subset request form for logging in. This of course means that passwords are not being hashed. Also, I can be positive that the keystrokes used for the subset, are recorded and are visible to staff ("you have the correct letters, just try turning off CapsLock" was one response I got).
If only there were malevolent hackers that could create I don't know automated post (please let it be post!!!) requests . That would be brute forcing nightmare.
[+] [-] fdej|12 years ago|reply
[+] [-] a_bonobo|12 years ago|reply
Edit: Australia seems to be using the US system: http://www.bitdefender.com/security/hacking-virgin-mobile-us...
[+] [-] mcv|12 years ago|reply
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.
[+] [-] acheron|12 years ago|reply
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.)
[+] [-] nchlswu|12 years ago|reply
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
[+] [-] jchung|12 years ago|reply
[+] [-] dougedey|12 years ago|reply
However, they didn't tell me (or anyone) so I've been telling everyone I know to update their password to be longer.
[+] [-] hluska|12 years ago|reply
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...
[+] [-] raverbashing|12 years ago|reply
But yeah, it's stupid
[+] [-] raesene3|12 years ago|reply
[+] [-] mitosis|12 years ago|reply
I guess that means they're wide open to denial of service attacks, but that's another story.
[+] [-] fuzzix|12 years ago|reply
Try PIC X(6).
[+] [-] lurkinggrue|12 years ago|reply
[+] [-] pjc50|12 years ago|reply
[+] [-] jaredmcateer|12 years ago|reply
[+] [-] danpat|12 years ago|reply
I think the problem is that the people in charge of making decisions are gun-shy. Because of their inability to properly evaluate the security itself, it's also very difficult for them to properly evaluate people telling them what the security system should look like, and they've been burned by bad decisions in the past, so they take the "lalalala do nothing" approach and hope for the best. From their point of view, it's a perfectly reasonable approach to the problem.
[+] [-] nraynaud|12 years ago|reply
[+] [-] DanBC|12 years ago|reply
Assuming they asked the correct people in BG website accounts security, and those people said "it's to prevent brute force attacks" we do not know if that's the real reason they do it or if it's just what they say to people who ask.
What is really frustrating is that there is no possibility of getting this changed - allow people to paste their passwords and use rate limiting to catch brute forcing.
Having said that, some aspects of BG's computer system are horrific for customers so I don't doubt that they do stupid things for stupid reasons.
[+] [-] mattstocum|12 years ago|reply
[+] [-] tokenizerrr|12 years ago|reply
Do they think a brute force attack is done by someone copy-pasting in passwords?
[+] [-] abritishguy|12 years ago|reply
[+] [-] timdierks|12 years ago|reply
"@passy I'm mistaken about the website security certificate but avoiding pasting of passwords is good practice & protects our customers 1/2" https://twitter.com/BritishGasHelp/status/463679554306203648
"@passy especially when using public computers. Alpha numerical policy ensures your protection without making special characters necessary^S" https://twitter.com/BritishGasHelp/status/463681274092462080
[+] [-] KMag|12 years ago|reply
Clearing the clipboard would be annoying for people who commonly copy a bunch of text out of a document, log in to their bank, and then paste the text somewhere else, but I suspect this is a rare workflow for most people.
[+] [-] rwhitman|12 years ago|reply
[+] [-] grkvlt|12 years ago|reply
[+] [-] mixedbit|12 years ago|reply
[+] [-] tempodox|12 years ago|reply
[+] [-] DomBlack|12 years ago|reply
Surely if they are hashing the passwords in any form then it doesn't matter how long the password is or what characters it contains.
I understand perhaps the view is some people are not good at remembering passwords and so would forget a complicated password - but they are unlikely to use a long password or special characters if that's the case.
Or am I just missing something major here?
[+] [-] wzdd|12 years ago|reply
So, two problems: multiple interacting systems, which means you can't just fix one, you have to fix all of them; and lots of legacy code. Versus: there would certainly be quite a lot of pain to implement a new system, and the old one appears to be working.
[+] [-] frou_dh|12 years ago|reply
> ... if they are hashing the passwords in any form then it doesn't matter how long the password is ...
Max lengths aren't inherently stupid. Presumably no one thinks 250MB password submissions should be handled, so you will be picking some number (possibly imposed on you by your stack).
[+] [-] quchen|12 years ago|reply
[+] [-] PeterisP|12 years ago|reply
PIN isn't particularly vulnerable to brute force anyway, as number of failed authorisation attempts is strictly limited to something like 3, and a fraudster has to risk capture by being physically present at each attempt or 'trying out' a stolen card, and having their face recorded on cameras.
I haven't seen any advantages for using 6-digit or larger "passwords" for that particular scenario. The largest practical security benefit seems to come from enforcing random PINs and not allowing to choose - since the banks that allow to choose are vulnerable to "dictionary attacks" of trying the user's birthday (obvious from other stuff in a stolen wallet) and stuff like 1234.
Now, checking "signature" instead of chip&pin, now that's an example of blind trust.
[+] [-] chopin|12 years ago|reply
You can't lock accounts only protected by a password and accessible by anyone (via internet) this way as this would invite for Denial-of-Service attacks (locking your account with three failed attempts).
[+] [-] morsch|12 years ago|reply
[+] [-] eximius|12 years ago|reply
Is this not the case?
[+] [-] bowlofpetunias|12 years ago|reply
Your card is not a service to be secured, it's part of multiple layers of security (that don't end with the code or the card).
[+] [-] Dylan16807|12 years ago|reply
[+] [-] Nursie|12 years ago|reply
[+] [-] weavie|12 years ago|reply
[+] [-] reboog711|12 years ago|reply
When I ran a web-site with an e-commerce store that accepted credit cards; I was required to have PCI Compliance scans done.
One of the things they had me do was turn off the autocomplete on the password field with autocomplete="off". I have no idea how that makes things more secure.
A lot of the things they made me do in order to be PCI compliant made no sense to me. I think I spent a week trying to convince them that my "error" page which showed up when someone mistyped a URL was not a security risk and was not something I should remove.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] manicdee|12 years ago|reply
Never trust the client['s computer]. Disabling pasting is trusting the client's computer. Security in depth ends where the Internet starts.
[+] [-] tempodox|12 years ago|reply
[+] [-] TeMPOraL|12 years ago|reply
[0] - https://news.ycombinator.com/item?id=7704235
[+] [-] alexhektor|12 years ago|reply
http://ask.metafilter.com/221964/Why-does-PayPal-want-me-to-...
[+] [-] ahdkaw|12 years ago|reply
[+] [-] K0nserv|12 years ago|reply
[+] [-] troels|12 years ago|reply
[+] [-] venomsnake|12 years ago|reply
It is good that there is no such thing possible.
[+] [-] jglazko|12 years ago|reply