4 ms·

What's odd to me about this post and all of the responses in this thread so far is that everyone is only thinking about password length as a way to defend again

What's odd to me about this post and all of the responses in this thread so far is that everyone is only thinking about password length as a way to defend against online bruting attempts when in reality long passwords mostly serve to protect against offline bruting attempts. The reason you don't want 6 or 8 character passwords is that when your password hashes get dumped it's a lot easier to crack them.

throwaway201606 7y ago
"What's odd to me about this post and all of the responses in this thread so far is that everyone is only thinking about password length as a way to defend against online bruting attempts when in reality long passwords mostly serve to protect against offline bruting attempts. The reason you don't want 6 or 8 character passwords is that when your password hashes get dumped it's a lot easier to crack them." This is: i) not accurate and ii) bad info Password hash dumps are worthless if the password hashing scheme used is i)crypto-hashing based and ii) uses salt. 6-8 char passwords are not an issue under this scenario. Current password management best practice is to use both standard crypto-hashing algorithms and salt. https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) Almost all platforms use standardized crypto-hashing packages that come as standard libraries in the language these days and those require salt. Further, almost all banks will all use these packages. This is the reason you do not see rainbow tables these days, they are worthless in face of almost any current acceptable crypto-hashing implementation ... assuming one does break rule #1 of crypto and try to roll their own crypto ... https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own https://security.stackexchange.com/questions/18197/why-shoul... https://www.schneier.com/blog/archives/2015/05/amateurs_produc.html https://www.schneier.com/blog/archives/2015/05/amateurs_prod... .. ad nauseam Salting also has the additional benefit of making brute-forcing magnitudes of difficulty harder. This is because salting rules can be implement that always add non-standard chars.. https://en.wikipedia.org/wiki/Salt_(cryptography)#Common_mistakes https://en.wikipedia.org/wiki/Salt_(cryptography)#Common_mis... As others have said, the 6-8 chars limits are are a function of legacy system somewhere in the application chain (online banking is never a single platform, it is usually a front-end that talks to a standard backend that tellers, operations etc also access, usually some type of greenscreen app - which is where the password hashes end up).
- Thriptic 7y ago
  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.

throwaway201606 7y ago

"What's odd to me about this post and all of the responses in this thread so far is that everyone is only thinking about password length as a way to defend against online bruting attempts when in reality long passwords mostly serve to protect against offline bruting attempts. The reason you don't want 6 or 8 character passwords is that when your password hashes get dumped it's a lot easier to crack them." This is: i) not accurate and ii) bad info Password hash dumps are worthless if the password hashing scheme used is i)crypto-hashing based and ii) uses salt. 6-8 char passwords are not an issue under this scenario. Current password management best practice is to use both standard crypto-hashing algorithms and salt. https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) Almost all platforms use standardized crypto-hashing packages that come as standard libraries in the language these days and those require salt. Further, almost all banks will all use these packages. This is the reason you do not see rainbow tables these days, they are worthless in face of almost any current acceptable crypto-hashing implementation ... assuming one does break rule #1 of crypto and try to roll their own crypto ... https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own https://security.stackexchange.com/questions/18197/why-shoul... https://www.schneier.com/blog/archives/2015/05/amateurs_produc.html https://www.schneier.com/blog/archives/2015/05/amateurs_prod... .. ad nauseam Salting also has the additional benefit of making brute-forcing magnitudes of difficulty harder. This is because salting rules can be implement that always add non-standard chars.. https://en.wikipedia.org/wiki/Salt_(cryptography)#Common_mistakes https://en.wikipedia.org/wiki/Salt_(cryptography)#Common_mis... As others have said, the 6-8 chars limits are are a function of legacy system somewhere in the application chain (online banking is never a single platform, it is usually a front-end that talks to a standard backend that tellers, operations etc also access, usually some type of greenscreen app - which is where the password hashes end up).

Thriptic 7y ago
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.