Live data from Hacker News

We'd lose our security certificate if we allowed pasting

twitter.com

211–220 of 225 posts

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

#211
post #84

Earlier quoted context omitted.

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.

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.

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

#212
post #194

Earlier quoted context omitted.

Ah, in the UK it is standard for the machine to keep your card after three incorrect pin attempts. (at least I think it's the standard?)

I'm in the UK as well. I was actually thinking of Chip & PIN transactions, but you may be right about cash points.

Good point. wasn't thinking about that.

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

#213
post #155
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 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…

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

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

#214
post #185

Earlier quoted context omitted.

There is no such thing as just "security". If the expected loss of funds for the user is lower, it is more secure - for the user.

Actually that's subjective. If the overall fraud is lower then (potentially, I'm sure this doesn't actually happen) fees, charges, interest rates etc could be lower for all users, therefore they would benefit from security that lowered the overall cost of fraud and the overall number of incidences of fraud, even if individuals that directly experience fraud are worse off.

Yes, but "security" isn't "overall cost", its about risk. I am more secure, even if my expected cost is higher, if I don't directly bear any risk of unconsented loss even if the overall incidence of fraud is higher and I am paying a distributed share of those costs.

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

#215
post #185

Earlier quoted context omitted.

Actually that's subjective. If the overall fraud is lower then (potentially, I'm sure this doesn't actually happen) fees, charges, interest rates etc could be lower for all users, therefore they would benefit from security that lowered the overall cost of fraud and the overall number of incidences of fraud, even if individuals that directly experience fraud are worse off.

Yes, but "security" isn't "overall cost", its about risk. I am more secure, even if my expected cost is higher, if I don't directly bear any risk of unconsented loss even if the overall incidence of fraud is higher and I am paying a distributed share of those costs.

You always bear some risk of unconsented loss.

With EMV the risk of an incident is much lower.

The risk of not being able to recover the money may be higher.

You're more secure.

--edit-- I say may be higher because AFAICT there are no good figures on this.

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

#216
post #58

Earlier quoted context omitted.

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…

It's not at all common or best practices to run an expensive key derivation function browser side. Doing so adds little to no additional security -- if you don't trust the TLS channel then you are screwed any way you look at it.

It's not common, but running an expensive KDF client-side still greatly slows down a bruit force attack if the password hashes are stolen, without increasing load on your server. The fast one-way function run server-side then prevents the client from being able to submit a stolen hash, forcing an attacker with a list of stolen hashes to perform the full expensive bruit-force attack.

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

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

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

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

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

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.

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

#219
post #91

Earlier quoted context omitted.

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

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.

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

#220
post #140

Earlier quoted context omitted.

That was probably to prevent SQL injection, right?

Properly implemented parameterized SQL would allow '; drop table users; -- As a password without batting an eye.

Unless I'm missing something here, lacking parametrization is not the issue here. The issue is that it's obvious they are saving the password in plaintext instead of hashing it, otherwise the password would never get close to an SQL query to allow injection.
Post reply on HN