5 ms·

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

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?

nodata 12y ago
What if the password is one character long?
- bsilvereagle 12y 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.
danpalmer 12y 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 12y ago
  It will take these organisation years and lots of money to rebuild their reputations when their security malpractices catch up with them.
  - danielweber 12y ago
    I would love this to be true, since it would basically double my net worth, but it's very rare for a security incident to kill a company. Target is the exception, and just required two human sacrifices.
- danielweber 12y 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.
raesene3 12y 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 12y 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 12y 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_dh 12y 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 12y 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.)
  - bradleyjg 12y ago
    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.
    - KMag 12y ago
      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.
  - frou_dh 12y ago
    I didn't fail to understand it. Doing that clientside in JS is an anomaly.
  - nollidge 12y ago
belorn 12y 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 12y 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?
  - fwr 12y ago
    Do you not have to confirm outgoing wire transfers by inputting a code sent to your phone?
    - barry-cotter 12y ago
      Americans don't do wire transfers, they write checks. The level of kidding in the previous sentence is extremely low.
      - NateDad 12y ago
        Wire transfers tend to have a $35-$50 fee and require you to schlep down to the bank during business hours and fill out annoying paperwork. So, yeah, we don't use them except in emergencies.
        mcv 12y ago
        Do we have a misunderstanding of the meaning of "wire transfer" here? Surely you can just send money to someone else's account through the bank's internet banking website? How else do you pay for stuff like rent, and, well, anything, really?
nly 12y ago
Ditching symbols makes reciting passwords easier for telebanking.
- LukeB_UK 12y ago
  Telebanking should use a completely different password.

nodata 12y ago

What if the password is one character long?

bsilvereagle 12y 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.

danpalmer 12y 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 12y ago
It will take these organisation years and lots of money to rebuild their reputations when their security malpractices catch up with them.
- danielweber 12y ago
  I would love this to be true, since it would basically double my net worth, but it's very rare for a security incident to kill a company. Target is the exception, and just required two human sacrifices.
danielweber 12y 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.

raesene3 12y 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 12y 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 12y 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_dh 12y 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 12y 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.)
- bradleyjg 12y ago
  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.
  - KMag 12y ago
    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.
- frou_dh 12y ago
  I didn't fail to understand it. Doing that clientside in JS is an anomaly.
- nollidge 12y ago

belorn 12y 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 12y 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?
- fwr 12y ago
  Do you not have to confirm outgoing wire transfers by inputting a code sent to your phone?
  - barry-cotter 12y ago
    Americans don't do wire transfers, they write checks. The level of kidding in the previous sentence is extremely low.
    - NateDad 12y ago
      Wire transfers tend to have a $35-$50 fee and require you to schlep down to the bank during business hours and fill out annoying paperwork. So, yeah, we don't use them except in emergencies.
      - mcv 12y ago
        Do we have a misunderstanding of the meaning of "wire transfer" here? Surely you can just send money to someone else's account through the bank's internet banking website? How else do you pay for stuff like rent, and, well, anything, really?

nly 12y ago

Ditching symbols makes reciting passwords easier for telebanking.

LukeB_UK 12y ago
Telebanking should use a completely different password.