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.
We'd lose our security certificate if we allowed pasting
211–220 of 225 posts
Re: We'd lose our security certificate if we allowed pasting
#212Earlier 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.
Re: We'd lose our security certificate if we allowed pasting
#213They 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…
Re: We'd lose our security certificate if we allowed pasting
#214Earlier 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.
Re: We'd lose our security certificate if we allowed pasting
#215Earlier 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.
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
#216Earlier 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.
Re: We'd lose our security certificate if we allowed pasting
#217They 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.
Re: We'd lose our security certificate if we allowed pasting
#218They 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.
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
#219Earlier 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.
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
#220Earlier 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.