Very 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.
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.
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.
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.
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.
> 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.
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.
snowstormsun|1 year ago
> 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.
entuno|1 year ago
So that 99 years is a massive underestimate for any actually secure password storage.
unknown|1 year ago
[deleted]
4death4|1 year ago
NegativeK|1 year ago
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.
reify|1 year ago
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.
entuno|1 year ago
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.
smarm52|1 year ago
dietr1ch|1 year ago
But yeah, a big goal here was to be as clickbaity as possible.
Hasz|1 year ago
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.
sebzim4500|1 year ago
Shank|1 year ago
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
lionkor|1 year ago
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.
Pesthuf|1 year ago
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…
ranger_danger|1 year ago
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)
skilled|1 year ago
https://www.hivesystems.com/blog/are-your-passwords-in-the-g...
alanfranz|1 year ago
adverbly|1 year ago
Something like secret or key would probably have been more appropriate in hindsight.
atmanactive|1 year ago
Lex-2008|1 year ago
> 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.
ses1984|1 year ago
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.
unknown|1 year ago
[deleted]