Live data from Hacker News

We'd lose our security certificate if we allowed pasting

twitter.com

61–70 of 225 posts

Re: We'd lose our security certificate if we allowed pasting

#61
post #3

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.

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

Re: We'd lose our security certificate if we allowed pasting

#62
post #29

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.

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.

Re: We'd lose our security certificate if we allowed pasting

#63
post #40

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 password…

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

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.

Re: We'd lose our security certificate if we allowed pasting

#64
post #49

Earlier quoted context omitted.

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

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.

Re: We'd lose our security certificate if we allowed pasting

#65

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…

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

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

Why do you think it's standard?

Re: We'd lose our security certificate if we allowed pasting

#66
post #51
post #48

Earlier quoted context omitted.

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 st…

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

It's pretty standard in the UK

Re: We'd lose our security certificate if we allowed pasting

#67
post #46

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…

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.

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.

Re: We'd lose our security certificate if we allowed pasting

#69
post #45

Earlier quoted context omitted.

Interestingly, the signature could be argued to be better in some cases: Under British law, a forged signature is never your fault, and the bank/merchant/card processor are liable (I can't remember exactly which, I think it depends). One of the reason that card issuers were so keen to switch to Chip&PIN/EMV is that the liability was turned over to the user . As they thought EMV was "unhackable", always a dangerous th…

>> One of the reason that card issuers were so keen to switch to Chip&PIN/EMV is that the liability was turned over to the user. Not really true. The main reason was the switch in liability to the merchant, if the merchant accepted a transaction without using EMV and PIN. AFAICT the Cambridge research isn't really that relevant, it doesn't really give you practical attacks, and it's not so much a crack on the chip se…

Cambridge University Computer Science student here.

Not all of the research that has been done has been published, I've seen some very impressive demos!

In any case the published research absolutely does give you practical attacks e.g. http://www.cl.cam.ac.uk/research/security/banking/nopin/

or http://www.cl.cam.ac.uk/research/security/banking/intercepto...

Re: We'd lose our security certificate if we allowed pasting

#70
post #29

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.

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

Post reply on HN