> 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.
So that 99 years is a massive underestimate for any actually secure password storage.
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.
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.
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.
But yeah, a big goal here was to be as clickbaity as possible.
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.
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
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.
That said, "double your password complexity/length" shouldn't be a problem if people are actually using password managers.
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.
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…
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)
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.
Something like secret or key would probably have been more appropriate in hindsight.
> 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.
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.
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.
