3 ms·

So let's assume a 6 character alpha-numeric password with upper and lowercase. 36^6 possible passwords or about 2.1 billion. The article linked is one guy and

So let's assume a 6 character alpha-numeric password with upper and lowercase. 36^6 possible passwords or about 2.1 billion. The article linked is one guy and one machine who can do 156 bcrypt hashes per second, with salted hashes. That's ~161 days to hash them ALL. If you have a dump of thousands of passwords it's extremely probable to get a few of them in under a day. Which is what the article shows - common short passwords were owned. What's funny about the additional restrictions (you must use 2 upper, 2 lower, etc.) is that they reduce the complexity of this problem so there are fewer possibilities the attacker needs to check for. So you're making it more difficult for users while decreasing actual security against this kind of attack. Much better policy is something like, "at least 16 characters, whatever ones you want." Easier for users because then passphrases are possible, easier to implement because there's only a string length check on the client, and more secure because it doesn't completely rely on users not choosing trivial passwords.

FabHK 7y ago
> common short passwords were owned. > What's funny about the additional restrictions (you must use 2 upper, 2 lower, etc.) is that they [...] decreasing actual security against this kind of attack. Not necessarily - the additional restrictions might prevent even more common short passwords from being used by the users, thus making it harder for both the user and the attacker. (If the bank says you can't use "Password" as your password, then yes, the attacker only needs to check 62^8 - 1 passwords instead of 62^8, making it insignificantly "easier" for the attacker, but at the same time a lot of people must switch from "Password" to something else, making it much harder for the attacker). EDIT to add: Having said that, what you propose (at least 16 chars, no other restrictions) makes perfect sense (maybe introduce a maximum of 32k chars).
throwaway201606 7y ago
Thanks for taking the time to explain this. I get the math and the idea that one password can have all combinations hashed in 161 days for this specific scenario - which is a 6-8 char password that does not allow non-alpha-numerics. I do think I forgot to add that I was thinking about all of this not just as a theoretical problem but in the context of a single end goal: accessing some random's bank account for some large {randoms} through some front end tool that is protected a 6-8 char password. Keeping this in mind: running this 161 day process results in a list of 32 billion hashes - useful only for a single account - that you really cannot do anything with since: i) you don't have bank's stored hash to test against and ii) you can't use the front-end access to test a hash If an attacker has back-end access to some DB or app to test the hash, you didn't need the hash in the first place to do nefarious stuff. You are already in. Point being that, yes, I do get it now that a 6-8 char password is much weaker in that it can be cracked in 161 days. But it is a really expensive attack to mount for a single account that may not even hold the cost of hardware and time spent mounting it. This strategy just does not scale to huge volumes of accounts. From a bank's risk management perspective, the potential losses associated with a successful attack of a single account in this fashion are more than manageable. It is cheaper, long term, to refund a clients up to $YYMM than it is to pay for one-time development work across all platforms to remove the 6-8 char restriction. Remember that security posture here has multiple layers. For example, for accounts with significant funds, you can definitely get in the front end with this approach but once in, you still have to deal with other protection schemes before being able to tap into any funds (e.g. multiple 2FA / RSA / PIN / keyword challenges, IP and/or time of day and/or destination gating etc ).

FabHK 7y ago

> common short passwords were owned. > What's funny about the additional restrictions (you must use 2 upper, 2 lower, etc.) is that they [...] decreasing actual security against this kind of attack. Not necessarily - the additional restrictions might prevent even more common short passwords from being used by the users, thus making it harder for both the user and the attacker. (If the bank says you can't use "Password" as your password, then yes, the attacker only needs to check 62^8 - 1 passwords instead of 62^8, making it insignificantly "easier" for the attacker, but at the same time a lot of people must switch from "Password" to something else, making it much harder for the attacker). EDIT to add: Having said that, what you propose (at least 16 chars, no other restrictions) makes perfect sense (maybe introduce a maximum of 32k chars).

throwaway201606 7y ago

Thanks for taking the time to explain this. I get the math and the idea that one password can have all combinations hashed in 161 days for this specific scenario - which is a 6-8 char password that does not allow non-alpha-numerics. I do think I forgot to add that I was thinking about all of this not just as a theoretical problem but in the context of a single end goal: accessing some random's bank account for some large {randoms} through some front end tool that is protected a 6-8 char password. Keeping this in mind: running this 161 day process results in a list of 32 billion hashes - useful only for a single account - that you really cannot do anything with since: i) you don't have bank's stored hash to test against and ii) you can't use the front-end access to test a hash If an attacker has back-end access to some DB or app to test the hash, you didn't need the hash in the first place to do nefarious stuff. You are already in. Point being that, yes, I do get it now that a 6-8 char password is much weaker in that it can be cracked in 161 days. But it is a really expensive attack to mount for a single account that may not even hold the cost of hardware and time spent mounting it. This strategy just does not scale to huge volumes of accounts. From a bank's risk management perspective, the potential losses associated with a successful attack of a single account in this fashion are more than manageable. It is cheaper, long term, to refund a clients up to $YYMM than it is to pay for one-time development work across all platforms to remove the 6-8 char restriction. Remember that security posture here has multiple layers. For example, for accounts with significant funds, you can definitely get in the front end with this approach but once in, you still have to deal with other protection schemes before being able to tap into any funds (e.g. multiple 2FA / RSA / PIN / keyword challenges, IP and/or time of day and/or destination gating etc ).