This is misleading, if the password is a certain length, then it might as well be considered secure. You could safely release hashes.

I'll pay you $10k if you can crack this sha512 hash.

I'd offer a million, but I don't have that kind of money.

5a55b7b0e1f9452f925b1aa43cf148081da58c66c735961d9a7cb699b2fd5b08bee6b24ec47fce0b93ba49df83641a30c7843dece49e0a0db5a7c50901492fdd

It's technically true that all cryptography is just slowing things down, but we are talking about heat death of the universe lengths of time for most crypto algorithms.

*assuming quantum computing doesn't take off or a fundamental flaw isn't found in the crypto.

The weakpoint is, has, and will always be people. They're cryptographic hashes of people's chosen passwords. You aren't attacking hypothetical mathematical entropy, you're attacking human imagination and laziness.

It isn't academic either. I have broken tons of cryptographic hashes in my career. Most of my colleagues have too. From DES through bcrypt over tens of years. The cost/performance has slowed, but the techniques haven't changed one bit because PEOPLE haven't changed one bit.

Obviously nobody can crack a sha512 hash likely containing a randomly generated cryptographic number. But that's irrelevant, because we're discussing the Plex security incident where humans created passwords, and humans today, tomorrow, and ten years ago are just as incapable of creating good passwords.

So their claim that these hashes "cannot be read" is inaccurate. If you have a modest budget and want to target a handful of accounts, there are multiple CHEAP cloud services that will happily sell you compute to do so.

Some humans use password generators though, so those should be safe

Some people eat mostly fresh fruits, vegetables, and whole grains.

The other 99.9% enjoy junk food, and don't use password generators.

sha* is a horrible choice for storing passwords. It's intended use is for verifying data integrity.

You should be using the solutions readily available instead of trying to reinventing the wheel, or avoid this subject altogether if you can't be bothered to educate yourself as to why.

This has been a decades-long issue, and it blows my mind how people in IT still didn't get the memo.

Use argon2, scrypt or even bcrypt who all are designed for keeping passwords secure with regards to brute force cracking.

I agree, but the entropy of the string that produced that hash will nullify any such disadvantage.

One of the aspects of MtGox's database leak that I found most fascinating to watch was the public effort to figure out users' passwords from the hashes. Checking common passwords, patterns, and people's public interests on Twitter was all shockingly effective.

This sounds fascinating. Has there been any literature produced on this specific incident and unfolding attempts?

Technically you may have to burn more entropy than exists in the visible universe, so its a possible if in the case of the right hash and luck.

Maybe this is naive, but in a good crypto system, I would hope "when" is measured in millions or billions of years given current hardware capabilities.

If you have a long enough and random enough password, you're probably good. The trouble with short passwords is that there just aren't that many of them. An attacker can just compute the hash of all of them.

As long as the salt is secret from the attackers (which is not a given, of course), the length of the passwords shouldn't matter all too much; the input to the hash (i.e. password + hash) would still have enough entropy to not be brute-force-able.

If you have the hashed password, in most systems you have the salt. Salt+hash is for preventing the attackers from getting to try all your passwords in parallel.

You can also have a system salt(s) that are not stored with the database, so that if someone accesses the database they have to guess password and two salts, one of which they hopefully do not have via the same penetration.

Maybe this is what you're saying, I'm not sure - my understanding was that the salt prevents reused passwords from resulting in the same hash. So, if I use 'password' and you use 'password' the salt+hash will be different. That way attackers can't just hash all the common passwords once and immediately associate them with different accounts.

Yeah, exactly. Commonly, the salts are stored right next to the hashes in the DB, because they serve their purpose even if the attacker knows what the salts are. By using a different salt for every password, the attacker needs execute a full "guess, hash, compare, repeat" attack on each user, as opposed to "guess, hash, compare against all user passwords, repeat" on the entire database.

For all practical purposes what you're saying is just wrong.

I've done so within the last year, successfully. Cost $7 for a single password in just compute and took about 17 hours (lowest, cheapest priority).

So please explain your reply further. Also recall their claim for context of what I was replying to, and what you're here defending now.

If their claim is credible what I did and what you're reiterating wasn't possible.

No you haven't, not for a reasonably strong password.

You brute forced a random argon2 hashed password using cheap compute in 17 hours?

Granted the suggested defaults for argon2 is like ~0.1 second per verification on a rather beefy CPU, in 17h that's about 620 000 guesses.

Your cheap compute would likely perform worse.

That is beyond improbable. You are making it up.

Your story lacks important context. Was the password "password"? "123456"? Or a 12-character mix of cases, numbers, and special characters?

> (e.g. salt + pepper + argon2 w/high factors) they can still be reverse engineered. It is a matter of when, not if

How much compute/gpu and hard dollars would hackers need in order to reverse engineers those stollen passwords?

They borrow unsecured k8s clusters on AWS. That’s not redis running…

Approximately “infinite”.