Live data from Hacker News

We'd lose our security certificate if we allowed pasting

twitter.com

91–100 of 225 posts

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

#91
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 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

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

#93
post #91
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 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 restr…

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.

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

#94
post #48

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…

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…

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

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

#95
post #46

Earlier quoted context omitted.

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.

For a password field, "autocomplete" doesn't mean to suggest candidate completions, but rather to prefill with the password part of a previously saved username-password pair, and to offer to save such a pair (or update an existing one with a newly entered and different password) when the form is submitted. Giving the field an "autocomplete" attribute with the value "off" disables this behavior, which matters for PCI compliance because it forestalls browsers from storing the password when they might do so insecurely.

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

#96
post #84
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.

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.

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

#97
post #58
post #40

Earlier quoted context omitted.

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

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. (Wher…

I didn't fail to understand it. Doing that clientside in JS is an anomaly.

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

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

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

#99
post #85

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

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.

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

#100
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?

"what do you mean about the phone"

Both my personal use credit union, and the bank my volunteer gig uses, have an outsourced authenticator who logs the ip addresses I use, and if I'm attempting to log in from a new address they SMS or voice call a number on file with a six digit number I type in to authenticate the new device. Neither the CU or bank have anything to do with each other, but use the same system, so I'm guessing its some kind of nationwide outsourced system that "many" financial institutions use.

Still have to enter your password to verify its me on my computer today, and not my kid screwing around on my computer, they only SMS authenticate perhaps once a month.

The same outsourcer apparently does password recovery when you get locked out. The bank requires full password recovery process if you don't log in for 45 days, which is an unholy annoyance for a sleepy volunteer org. The life of a treasurer is never easy I guess.

Its moderately annoying as my phone lives on its charger in the bedroom if I'm at home, and the desktop in the office is at least 75 foot walk away, so when the authentication service feels like pulling my chain, I swear a lot and make a trek and inevitably the login times out so I have to start all over again once I fetch the phone. Which fits in with stereotypical security theater, you "win" if you make it inconvenient, no need to actually make it secure.

(edited to add I live in the USA, upper midwest, vaguely near Chicago, everyone else responding is at least 4000 miles away, I interpreted your request as how they use phones to auth in the USA, so, well, this is how they do it)

Post reply on HN