We'd lose our security certificate if we allowed pasting

https://twitter.com/BritishGasHelp/status/463619139220021248

by mofle • 12 years ago

217 216 12 years ago

pjc50• 12 years ago

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.

nraynaud2• 12 years ago

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.

higherpurpose• 12 years ago

I was hoping the Target CEO firing/resignation due to security issues would spark a little bit of security interest from other companies, too.

danpat• 12 years ago

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.

jaredmcateer• 12 years ago

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.

quchen• 12 years ago

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.

morsch• 12 years ago

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?

eyko• 12 years ago

Unless you buy online, in which case you just need the "last 3 digits on the back of your card".

crashandburn44• 12 years ago

I actually rely on this self destruction, I have a scrap of paper in my wallet with "Pin Numbers" written on it along with 3 random four digit numbers, gives me minor peace of mind that if my wallet is lost and found by someone that wants to try and use them, hopefully they'll lose them to an atm rather than using them online.

oneeyedpigeon3• 12 years ago

A tiny number of digits combined with the standard, visible input system is a recipe for 'shoulder surfing' attacks. I'm not proposing a superior system, just pointing out that brute-force attacks are not the only thing to beware.

chopin• 12 years ago

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

koyote• 12 years ago

I have had quite a few sites block my account for three bad password attempts and I had to actually call the company to unlock the account (this was always a financial services company).

It's quite annoying as none of the sites warned me about the impending account block after the first or second try. I guess it's an inconvenience that is worth it for the extra anti-brute-force security. Being locked out due to someone personally locking you out as you mentioned might also be annoying, but I honestly rather be locked out of my account and therefore alerted that someone is trying to gain access to my data than not.

Why these same sites limit my password to a specific number of characters and disallow special characters is beyond me though.

eximius• 12 years ago

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

Is this not the case?

crashandburn44• 12 years ago

Great, now I need to change all my pin numbers. :)

casualbob_uk• 12 years ago

I believe some cash machines in the UK don't require you to press 'enter' after typing in your code, they just 'go' after 4 have been entered.

PeterisP2• 12 years ago

It's not the case, it depends on the issuing institution.

Also, there is a practical requirement to have it short; as physical merchants value quick processing, and having to type&re-type long passwords delays other people behind you - so they want long PINs to be unpopular.

relix• 12 years ago

Not common, and using anything other than 4 digits is not wise if you want universal support especially when travelling - 6 digit cards are not 100% compatible with every ATM/card machine because some (most?) only allow 4 code entry. I've never heard of 10 digits and the compatibility must be even more limited. Where do you live and what happens if you try to use your card at ATM's abroad?

huhtenberg• 12 years ago

Mine was 8 until I came to visit certain European country where every single terminal has PIN length capped at 6. The best vacation I ever had.

PeterisP2• 12 years ago

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.

penguat• 12 years ago

No need to be physically present anywhere except where the card is, and as for cameras, I see none on a PINSentry: https://www.google.co.uk/search?q=pinsentry&source=lnms&tbm=...

praptak• 12 years ago

Now, checking "signature" instead of chip&pin, now that's an example of blind trust.

If even. I cannot find the original report, but there was a guy who tried all kinds of weird signatures including "I STOLE THIS CARD" and it only took purchasing 3 most expensive TVs and signing "NOT AUTHORIZED" for someone to question him.

Unoriginal report: http://www.getrichslowly.org/blog/2006/07/29/the-credit-card...

heldtogether• 12 years ago

I was once refused a consumer credit application for a kitchen appliance because I'd forgotten to sign the back of my credit card. I had a passport and a photo driving license on me at the time but because there wasn't a signature they "couldn't be sure" it was me so they refused to process the application.

I signed it in front of them (which matched my passport signature BTW) but was politely declined as they'd seen the card unsigned.

Another example of security policy getting in the way of actual security.

Dylan168073• 12 years ago

Losing passwords is bad because they get reused. 4-digit pin not so much, debit card is basically the only thing that uses it.

SideburnsOfDoom• 12 years ago

You don't have to re-use passwords. In fact, don't re-use passwords. Keeping them in a password manager helps a lot with this. I have over 50 unique passwords which are all long, generated random strings. But there are a few websites, including British Gas, which get shitty weak passwords because they pull dumb crap like this in the name of "security".

oneeyedpigeon3• 12 years ago

Not true; the password on iOS devices is a 4-digit pin; in my experience, plenty of people either reuse their bank PIN, or just use their DOB.

Nursie5• 12 years ago

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.

madeofpalk• 12 years ago

Cards issued by Commonwealth Bank in Australia actually don't come with a PIN - you set it yourself, up to 12 chars, online when you activate.

bowlofpetunias• 12 years ago

No, limited transactions on your bank-account are secured by a physical token (i.e., your debit card) and a 4 digit "password".

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

weavie• 12 years ago

You get contact-less now which doesn't need any pin at all, just tap the card on the machine and your purchase is complete.

DomBlack• 12 years ago

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.

Or am I just missing something major here?

nodata2• 12 years ago

What if the password is one character long?

bsilvereagle• 12 years ago

DomBlack is referring to max length. For example several banks limit you to a 12 character long password and then don't allow special characters.

danpalmer2• 12 years ago

In the 1980s I don't think hashing passwords was common, it would have taken too much processing power, and the database fields on the mainframe don't support weird characters or a length of more than 8 characters.

I wish this wasn't the case, but these systems are so old behind the scenes, that lots of it simply can't be changed without massive re-engineering. I have friends that work for a company who transfer COBOL applications from mainframes to JVM COBOL running on standard servers, it's a massive task, and takes years and lots of money.

crbaker• 12 years ago

It will take these organisation years and lots of money to rebuild their reputations when their security malpractices catch up with them.

danielweber5• 12 years ago

It was standard to hash passwords in /etc/passwd back in the 1980s.

Still, when you pin code is limited to 1 million combinations, all the hashing in the world isn't going to save you. You need to keep your DB secure, no matter what, and that's where resources were applied.

raesene33• 12 years ago

Some of this kind of system won't actually hash the password but encrypt it and use an HSM to secure the keys.

Wherever you see a password prompt where the ask for specific characters of the password, they're either doing this or shudder storing it in the clear.

wzdd• 12 years ago

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.

cLeEOGPw• 12 years ago

So it's a problem where the system must be kept up running no matter what and refactoring everything might cost more than having some security threats? Or is it just plain greed and "while it's working now, why fix it?" kind of thing.

frou_dh3• 12 years ago

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

mcherm• 12 years ago

I think you failed to understand the second point you quoted.

A 250MB password should be perfectly valid (if a bit foolish on the customer's part). That 250MB password will be run through scrypt by javascript running on the browser. (That may take a while, and a large amount of memory, but this is part of the CUSTOMER'S stack, not the server's.) Some amount, perhaps 512 bits worth, is then passed to the server. (Where it is run through another hash and then stored.)

lmm• 12 years ago

If you're hashing it who cares if someone wants to submit a 250MB password? They'll only be slowing their own session down - what I store in the database is always 256 bits either way.

Spittie• 12 years ago

A 250MB requests should get blocked by your web server way before it touches your code or your database.

But yes, you're right, limiting passwords can help avoiding edge cases where a long password is not handled correctly ecc... Just pick a sane length that no-one will hit, like 1000 chars or more.

TheLoneWolfling• 12 years ago

English has at least ~0.6 bits of entropy per character, probably (much) more, depending. (Got that from Wikipedia, so don't know how accurate that is)

So even if you are using an English passphrase, the logical upper bound for a max password length is ~1.7x the length of the hash you use.

belorn• 12 years ago

If a bank use passwords at all, its a big red sign that they only care about the appearance of security. A password do not strongly identify a person, and should not be used for anything that involve high value and easy stolen property.

Most banks I know uses pin and either a hardware token or a bound smart phone. Its far from perfect, but at least someone has to steal a physical object or hack the phone system to start their brute-force attacks.

err4nt• 12 years ago

"Most banks you know"? I'm genuinely curious, I don't know of any bank like that in Canada, and I'm in the US weekly and I've never heard or seen it there. I've seen token generator keychains, but what do you mean about the phone?

alistairSH• 12 years ago

Not in the US. Not one of my banks or other finance-related websites uses two-factor authentication by default. I haven't looked to see if any offer it as an option, but I tend to doubt it (it certainly isn't advertised).

mcv5• 12 years ago

A pin is just a very short password. A bank using only a password would of course be ridiculously negligent. All banks I'm familiar with use 2 levels of authorization: 1 to log in, 1 to authorize payment.

I have 2 bank accounts. One with ING (a major Dutch/international bank), which uses a password (without special characters unfortunately) to log in, and an authorization code to authorize payment. In my case, that authorization code comes from a piece of paper with a bunch of one-time codes on it. This is an old system that dates back to when you called them directly by modem, rather than over internet. Nowadays I could also have the code sent to my phone. But phones can also be stolen, so I don't see the point.

My other account (at Triodos, a much smaller Dutch bank) uses a pin + hardware token at both stages. I wouldn't also having a ridiculously long password there.

nly• 12 years ago

Ditching symbols makes reciting passwords easier for telebanking.

LukeB_UK• 12 years ago

Telebanking should use a completely different password.

fdej• 12 years ago

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.

raesene33• 12 years ago

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)

a_bonobo• 12 years ago

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

V-2• 12 years ago

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

scrabble• 12 years ago

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

kleim2• 12 years ago

Same goes for Virgin Mobile France.

freditup2• 12 years ago

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

sehrope• 12 years ago

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?

dougedey2• 12 years ago

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.

abdullahkhalids• 12 years ago

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

randlet3• 12 years ago

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

etimberg2• 12 years ago

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.

acheron• 12 years ago

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

robryk• 12 years ago

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.

raverbashing• 12 years ago

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

mcv5• 12 years ago

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.

Kudos3• 12 years ago

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.

lfuller• 12 years ago

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

kleim2• 12 years ago

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

jfoster• 12 years ago

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.

nchlswu• 12 years ago

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

Afforess• 12 years ago

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.

KMag4• 12 years ago

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.

mitosis• 12 years ago

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.

jchung• 12 years ago

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?

fuzzix• 12 years ago

stored as a char(6)

Try PIC X(6).

hluska• 12 years ago

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

astrodust• 12 years ago

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

agersant• 12 years ago

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

lurkinggrue2• 12 years ago

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

tzs• 12 years ago

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.

K0nserv• 12 years ago

OSx does the same thing when entering passwords for private keys through the keychain

reboog7112• 12 years ago

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.

ipedrazas• 12 years ago

Do not complain... they know better, you see, they are "the experts"

droope• 12 years ago

autocomplete=off does not prevent you from using keepass, it prevents your browser from storing your password in your HD in plaintext.

It's arguable that it's not the website's decision where the user caches it's passwords, but in high security environments I don't think it is an overkill.

TheRealWatson• 12 years ago

I doubt the autocomplete browser feature applies to password entry. It would freak people out if their browser started suggesting the password as you typed. It does apply for the username/email field, though.

reboog7112• 12 years ago

That makes sense to me in a way I didn't think of before.

iancarroll2• 12 years ago

It's standard security practice to disable autocomplete for secure pages.

nodata2• 12 years ago

No it's not. Most big websites (hello google!) don't do this.

Why do you think it's standard?

mixedbit• 12 years ago

Reminds me of a password security policy that listed few SQL statements that can't be used in passwords.

tempodox2• 12 years ago

That was probably to prevent SQL injection, right?

Zikes• 12 years ago

Properly implemented parameterized SQL would allow

    '; drop table users; --

As a password without batting an eye.

oneeyedpigeon3• 12 years ago

Can you really prevent SQL injection via a blacklist?

leetrout• 12 years ago

Citi is the same way...

Nothing in their policy about what isn't allowed[0] and they updated their system one weekend and my password quit working because it had % in it. I called tech support over it and they offered no additional guidance.

https://www.accountonline.com/cards/svc/OutsideView.do?forwa...

ceejayoz• 12 years ago

In the worst possible way - it makes clear that they're vulnerable to it.

jglazko• 12 years ago

Thanks for sharing. Made a great start to my day. I just the callers don't starting asking why we allow it!

venomsnake• 12 years ago

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.

It is good that there is no such thing possible.

troels• 12 years ago

'Brute Force'? I do not think it means what he thinks it means.

DanBC• 12 years ago

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.

mattstocum• 12 years ago

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.

crazypyro2• 12 years ago

Its way worse with the advent of social media consultants/reps because their stupid explanation gets saved for the entire world to see, even if its about a section of a multi-billion dollar company they have no idea about. Low level reps have never had such an impact on companies as they do on social media.

abritishguy2• 12 years ago

The reason is irrelevant - there is no reason why you should do this.

tokenizerrr• 12 years ago

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?

alexhektor• 12 years ago

Papyal does this in some scenarios as well. For one of my accounts, I can't paste the password from a password manager. Does no one here know why?

http://ask.metafilter.com/221964/Why-does-PayPal-want-me-to-...

ahdkaw• 12 years ago

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

tempodox2• 12 years ago

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.

TeMPOraL• 12 years ago

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.

[0] https://news.ycombinator.com/item?id=7704235

timdierks• 12 years ago

The tweeter (probably a non-technical support person, so go gently on him or her as an individual) has revised the statement:

"@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

rwhitman• 12 years ago

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.

zaroth2• 12 years ago

Makes no sense at all... Where ELSE might I be able to paste the contents of my clipboard?

Now, clearing the clipboard AFTER pasting, that might actually make sense!

grkvlt• 12 years ago

Good advice. On a public computer you really don't want people accidentally leaving their password in the cut buffer for the next user to find.

KMag4• 12 years ago

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.

We'd lose our security certificate if we allowed pasting

Related Stories