3 ms·

I'm not talking about rainbow tables or hash tables, I'm talking about straight up bruting with GPUs and hashcat. You seem to be implying that using a salt adds

I'm not talking about rainbow tables or hash tables, I'm talking about straight up bruting with GPUs and hashcat. You seem to be implying that using a salt adds entropy, but the salt is known (plaintext) and it's added in a set way so it doesn't. Sure your choice of algorithm and complexity factor will definitely affect your guess rate and ease of bruting, and yes using a salt prevents the use of precomputed hash tables, but it's not like it's impossible to crack a salted 6-8 character password hashed with bcrypt if you throw enough GPUs at the problem. The only question is if it's cost effective.

throwaway201606 7y ago
Am confused here, is there something I am missing ? Brute-forcing bcrypt-hashed passwords on GPUs has a ridiculously low success rate even on most commonly used password data sets. Failure rate on passwords outside the most commonly used list is more than 95% https://arstechnica.com/information-technology/2015/08/cracking-all-hacked-ashley-madison-passwords-could-take-a-lifetime/ https://arstechnica.com/information-technology/2015/08/crack...
- drblast 7y ago
  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 ).
jcrawfordor 7y ago
This is even more important because banking systems with legacy password limitations (e.g. 8 characters) generally imply that there's also legacy password management - meaning that it's very possible the approach to hashing is outdated. bcrypt or scrypt is a best practice but it's far from universal in brand new software, the systems these banks are using were likely developed before either algorithm was published. I'm even ignoring here that many banks at least recently used to provide strong hints that they are storing passwords in plaintext, such as by using a modified form of the password as a telephone passphrase.

throwaway201606 7y ago

Am confused here, is there something I am missing ? Brute-forcing bcrypt-hashed passwords on GPUs has a ridiculously low success rate even on most commonly used password data sets. Failure rate on passwords outside the most commonly used list is more than 95% https://arstechnica.com/information-technology/2015/08/cracking-all-hacked-ashley-madison-passwords-could-take-a-lifetime/ https://arstechnica.com/information-technology/2015/08/crack...

drblast 7y ago
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 ).

jcrawfordor 7y ago

This is even more important because banking systems with legacy password limitations (e.g. 8 characters) generally imply that there's also legacy password management - meaning that it's very possible the approach to hashing is outdated. bcrypt or scrypt is a best practice but it's far from universal in brand new software, the systems these banks are using were likely developed before either algorithm was published. I'm even ignoring here that many banks at least recently used to provide strong hints that they are storing passwords in plaintext, such as by using a modified form of the password as a telephone passphrase.