Nvidia's flagship gaming GPU can crack complex passwords in under an hour
tomshardware.comVery click baity and not good journalism imho. Starting with a "A GeForce RTX 4090 could be cracking your password at this moment." tag line only to later note:
> With bcrypt, the hashing times soared. While the GeForce RTX 4090 only took 59 minutes to crack an MD5 hash, the same graphics card would need 99 years.
It's 2024 and if your password is still being hashed with md5, the news are: Your password could have been cracked 10 or more years ago already. Nobody sane uses that anymore and bcrypt still stands the test.
And even worse, that's bcrypt with 32 iterations - a work factor of 5. Every Bcrypt implementation I've seen has a default work factor of 10 (1024 rounds), and people often use higher values that that.
So that 99 years is a massive underestimate for any actually secure password storage.
So 99 of them could crack a password in 1 year? That is easily obtainable and not secure at all.
If your password is only 8 characters. I go with a minimum of 14. That means 99 years turns into heat death of the universe... Or a pipe wrench.
It doesn't work that way - and if it did - it's absolutely acceptable in most, if not all systems. A year to "break something" is absolutely considered secure in risk management of larger systems.
How does it not work that way? Password cracking is infinitely parallelizable.
Technically yes - but when it comes to attacks not really. If someone wants it, you have much easier and faster techniques.
If you're a provider of some sort and storing passwords with MD5, shame on you. Or rc4. I'm looking at you, NTLM.
If you're a user and you don't assume that some providers are using MD5... That's just excessively risky.
It's not hard to manage passwords that can't be cracked regardless of the hashing algorithm.
What should I be doing to make a password that can't be cracked regardless of the hashing algorithm?
start using very high entropy passwords which contain just about all printable ascii characters, excluding whitespace.
If a computer cant guess it, it won't crack the hash, either.
Use a password manager and make those suckers 20-40 characters.
Use a master key that is just a super long phrase interleaved with special characters. Easy to remember. Like titles of books you like, plus authors, plus something only you know. Stuff like that.
I use a version of KeePass, with the actual file synced via syncthing to all devices plus a cloud.
Using an 8 char password for those tests is very weak
On my old linux gaming rig with the AMD RX580 I can run through the entire WPA2 keyspace of 8 char lowercase or 8 char uppercase in 3 hours.
Md5 and sha1 takes seconds using JTR or hashcat masks or brute force or a straight attack using the Rust super fast Cracken password generator.
Not to mention that they're using MD5, people have been recommending against for over a decade.
For the Bcrypt results waswas "99 years" even for an 8 character password (and with a work factor of 5, compared to the default of 10 in most libraries) - but that doesn't make for a a very good clickbaity headline, so they don't really talk about it.
Good spot. My passwords are ~20+ characters, so the title had me worried for a sec.
This and dice words for the win. God I hate password requirements that need special chars. Just add a min length and be done with it.
To be fair, everytime a privacy leak is reported we may be looking at old code or careless devs that may have used m5d or things like length as a hash function.
But yeah, a big goal here was to be as clickbaity as possible.
If anything, this approach shows how good a system passwords are. The downfall will be cheap quantum computers; it seems like we have some time until those are available.
An A100 is about $2/hr, so cracking even a "basic" password hashed with bcrypt is going to cost a cool $24M in GPU alone. Most people concerned about this kind of attack are using a whole lot more chars. Apps should not be using MD5, use pbkdf2 or bcrypt.
Quantum computers only provide a quadratic advantage to breaking hashes, using Grover's algorithm. This quadratic advantage will likely not be sufficient to overcome the enormous overheads of quantum computing for many decades. Especially since the higher the level of parallelism the smaller the benefit you get from Grover's algorithm.
> The downfall will be cheap quantum computers; it seems like we have some time until those are available.
This is limited to things that can be easily cracked with a quantum algorithm like public key cryptography via shor's algorithm.
"Quantum computers won't solve hard problems instantly by just trying all solutions in parallel." -- Scott Aaronson
Totally fair, I am conflating two pretty different things.
For symmetric crypto, there is Grover's algorithm, which we can mitigate by just doubling key size. However, for asymmetric crypto, shor's algorithm is going to wreck it; intelligence agencies are hoovering up traffic right now to crack latter when it's cheaply available.
I would point out the field is in its infancy and new attacks/discoveries will be made that will change things dramatically. These attacks also depend on having access to a "sufficiently large" quantum computer, which in my amateur opinion is 10s of years away from public availability.
There is a whole field of "post-quantumn" cryptography being discussed now, but they not really standard or ready for prime-time afaik.
It's been a very long time, but: wouldn't Grover's algorithm apply to password hashes, shortening effective bit length by half?
That said, "double your password complexity/length" shouldn't be a problem if people are actually using password managers.
I suppose if we look at the world strictly in terms of a "classic" hash, I believe the answer is yes. However, "modern" password hashes are designed to be memory and CPU intensive. Scrypt hashes, for example, are designed to "waste" cycles and memory to bolster security. The size of the underlying password can remain static while the requirements imposed by scrypt can change.
Granted, I'm sure many sites are still using bad hash-based algorithms like md5 without salt today. But modern applications are often built with the goal of slowing down even offline attacks with salting, memory consumption, and CPU cycle consumption. The goal isn't just slow, but costly.
I posted this below some comment but it may be worth reading for others:
start using very high entropy passwords which contain just about all printable ascii characters, excluding whitespace.
If a computer cant guess it, it won't crack the hash, either.
Use a password manager and make those suckers 20-40 characters.
Use a master key that is just a super long phrase interleaved with special characters. Easy to remember. Like titles of books you like, plus authors, plus something only you know. Stuff like that. Example: `Franz&Kafka$Meta-/morphosis@@3385`. Even better, use such helpers to make a high entropy string of random letters.
I use a version of KeePass, with the actual file synced via syncthing to all devices plus a cloud. To me, it has never been an issue to copy paste or auto type a 40 character password -- in fact, I usually dont even notice.
Not quite as unrealistic as it seems - I have colleagues I can’t convince that SHA-256 is NOT good for passwords.
They just don’t understand that it’s safe for larger binaries, but absolutely not for short ASCII strings like passwords. Also they find it convenient since most modern programming languages and databases directly support those hash functions, but not something like bcrypt or Argon2.
So I do think there are many passwords out there you can crack easily and quickly nowadays.
I’ll try convincing them again…
> SHA-256 is NOT good for passwords
Can you define SHA-256? And not good? Using it with PBKDF2/bcrypt/etc. seems to be widely accepted, but we don't know if you were referring to a single unsalted round of SHA-256 or what. Also by "not good" do you mean "easy to reverse the hash itself" or "easy to bruteforce the resulting password"? I think these questions make a big difference, e.g. you could have the most complex hashing algorithm on Earth, but if they're bruteforcing a three digit password, it doesn't matter.
(something something bitcoin uses sha2)
I thought it was obvious since I mentioned bcrypt and argon 2 later that I meant plain, simple, single round SHA-256. Usually salted, but there's one database where they're not, for some weird MySQL view compatibility hack that allows reusing the accounts and password hashes in a different legacy application that doesn't support salts whatsoever.
The reasons why this is terrible for storing password hashes are widely known, everyone else in the comments is already talking about how you're meant to use something like PBKDF2 or bcrypt instead, so I didn't see the need to put an explanation nobody needs in my comment.
Horrible article. You could crack md5 hashes in hours like 15 years ago. Nobody barely serious uses md5 for password derivation since long.
The label password is terrible. It implies that a single word is sufficient.
Something like secret or key would probably have been more appropriate in hindsight.
By the way, I don't understand how does password cracking work on a site/system that has fail-to-ban?
From the article:
> Servers store passwords in the form of hashes, so even if a hacker steals the database, they see the hashes, not the actual password.
So as I understand it, the article assumes that someone hacked a website where you had an account, and want to get your password (for the hacked website), in order to try using the same (username and) password to get access to your account on other websites.
Or, as other comments mentioned, they might intercept wifi authentication packets (which contain hash of the wifi password), and try to get wifi password from it.
Ah yes, thanks for the clarification. So, two mishaps are needed for this to work: a site needs to be hacked and the user database stolen, and, a person needs to use the same user/password for all sites. Takeaway: never use the same password twice. Got it.
AND that site has to be using unsalted MD5 password hashes, in which case you were already doomed
Salts do not make brute-forcing any more "difficult" though if that's the method you're using to crack with.
Of course this is correct (merely makes it so that you have to brute force instead of look up in your book)!
Generally speaking you can divide attacks like these into two types, online and offline.
In an offline attack, the attacker has somehow gained access to some encrypted and/or hashed secrets, and they're trying to break the encryption or reverse the hash. There's nothing getting in their way except for time and compute power.
In an online attack, there is some system in between the attacker and the target, like an authentication server, that can implement stuff like fail2ban, captchas, rate limiting, etc.
Even if they did not explicitly implement rate limiting, an online attack is going to take enormously longer to execute. Querying an online service is going to add say 100msec roundtrip on top of the actual password hashing time.
I thought guidelines were that passwords should take 500msec to calculate. So, call it 600 msec per submitted password. Many servers will melt before being able to respond to any serious brute forcing attempt.