4 ms·

I'm not up on this topic, but I've always wondered why password length is so important if dictionary and other automated attacks aren't allowed. I hope you don'

I'm not up on this topic, but I've always wondered why password length is so important if dictionary and other automated attacks aren't allowed. I hope you don't tell me that banks allow millions of password attempts in a short period of time, certainly not from the same ip address and even from what might be a bot net.

ufmace 14y ago
The usual concern is the database storing the passwords/hashes being stolen. This has happened to dozens of small to medium size web services. The attacker could then hash away at the passwords to his heart's content. Then end-goal of this is to get user/pass combos to be tried on other, higher-value sites, like email services and, uh, banks. Which gets us to the strange part. Who hacks a bank's service to steal a password DB in hopes of using the passwords against some other target? I'm thinking nobody. If you managed to compromise a bank's web service to that extent, you'd be trying to transfer all of the money from all of the user's accounts to one you control, not trying to crack their passwords. That means that your bank's password storage method and complexity is not very important. What is important is that, whatever password you use, you never use that password on any other site. And that you use a bank that requires real 2-factor authentication, via text or mobile app or something like that, not with "security questions".
- kc0bfv 14y ago
  If the passwords are stored somewhere that's easier to access than your real target at the bank, then cracking the passwords might be helpful... I totally agree with your recommendations, but bank password storage/complexity definitely could be important. If an attacker got hold of a large number of bank account user logins, I'm not sure what they'd do. My bank doesn't provide a feature to quickly transfer cash from the website... Several hundred large billpay changes would show up and be easy to cancel... Perhaps they'd just gather personal info useful to a social engineering attack...
- deleted 14y ago
  [deleted]

ufmace 14y ago

The usual concern is the database storing the passwords/hashes being stolen. This has happened to dozens of small to medium size web services. The attacker could then hash away at the passwords to his heart's content. Then end-goal of this is to get user/pass combos to be tried on other, higher-value sites, like email services and, uh, banks. Which gets us to the strange part. Who hacks a bank's service to steal a password DB in hopes of using the passwords against some other target? I'm thinking nobody. If you managed to compromise a bank's web service to that extent, you'd be trying to transfer all of the money from all of the user's accounts to one you control, not trying to crack their passwords. That means that your bank's password storage method and complexity is not very important. What is important is that, whatever password you use, you never use that password on any other site. And that you use a bank that requires real 2-factor authentication, via text or mobile app or something like that, not with "security questions".

kc0bfv 14y ago
If the passwords are stored somewhere that's easier to access than your real target at the bank, then cracking the passwords might be helpful... I totally agree with your recommendations, but bank password storage/complexity definitely could be important. If an attacker got hold of a large number of bank account user logins, I'm not sure what they'd do. My bank doesn't provide a feature to quickly transfer cash from the website... Several hundred large billpay changes would show up and be easy to cancel... Perhaps they'd just gather personal info useful to a social engineering attack...
deleted 14y ago
[deleted]