Comment by throwaway201606 | Hacker News Reader

Comment by throwaway201606 | Hacker News Reader

Parent Full thread

throwaway201606

"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)

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-shoul... 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_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).

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.

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/crack...

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.

> 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).

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 ).

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.

>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.

I don't think so. Unless you meant something other than cryptographic hashing when you say "crypto-hashing". SHA-256 is a cryptographic hashing function (much more likely to be used at a bank than something like bcrypt I would wager) and a GPU is going to do on the order of a billion hashes per second. So cracking a 6 character password in minutes.

A salt will make a set of passwords harder to crack en masse, but if they want your specific password, salting isn't going to make that any harder.

Reply on news.ycombinator.com