For an Nvidia 3090, you you can do around [1]:

MD5: 65 trillion guesses/second

SHA-512: 2 trillion guesses/second

Blowfish: 100k guesses/second

My root password is fairly short, since I type it all the time. I would be screwed if anyone had interest. I don't think relatively short root passwords are all that uncommon.

1. https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...

Nitpick: that’s bcrypt, not Blowfish. Blowfish is an encryption algorithm; bcrypt is a password hashing algorithm based on Blowfish, but designed to be significantly slower.

Also, bcrypt comes with a work factor that works on a log scale -- a work factor of 6 is 2^6 (64) rounds, and 6 is considered far too out of date these days. The default in hashcat is (IIRC) a work factor of 5 (2^5, 32 rounds).

If you're using 14 or higher, which is usually the recommendation thrown around these days, that 100k number will look more like single or double digits.

I assume these are for very short passwords? It dramatically increases in complexity with just a few extra characters, is it possible then to use a password that is 3~4 sentences long to defeat this?

5 characters (3 lowercase letters, 2 numbers) 365= 60,466,176

7 characters (1 capital letter, 6 lowercase letters) 527= 1,028,071,702,528

8 characters (4 lowercase letters, 2 special characters, 2 numbers)

688= 457,163,239,653,376

so in about 10 seconds it would be able to discover the latter which is absolutely insane to me. The only way is to increase the letters and special characters.

for instance a 12 character password (8 lowercase letter, 2 special, 2 #) would yield an unwieldly number of possibilities but given you can brute force 65 trillion per second at the lower end, we would be seeing an astronomical figure.

We might also see this brute force capacity dramatically increase thanks to Moore's law and then the sky is truly the limit.

a 32 character password would be broken within our lifetime in just a matter of years.

Or use multiple rounds of hashing to generate and validate the hash. IIRC about 5 years ago MS Office was using 500K rounds of SHA512 by default (as a keygen for decrypting documents), which meant about 8 guesses a second on a good machine. Of course you have to keep updating those specs as computing power increases over time.

Is there anything stronger than blowfish? seems like I would just do that 50,000 rounds of blowfish mixed with SHA512 rounds in between randomly. Good luck trying to brute force an excerpt from the Bible written in Japanese backwords using esoteric usage of special characters to top it off.

I expect this to take at least a few millenias to crack

Every time your password is used, you will experience that hash delay. So, for usability, it would be best to keep it to something not-annoying, and just change your password every once and a while.

> Is there anything stronger than blowfish?

I think you mean bcrypt..

Both Argon2 and scrypt win over that:

https://github.com/P-H-C/phc-winner-argon2 https://www.tarsnap.com/scrypt.html

>a 32 character password would be broken within our lifetime in just a matter of years

Won't you make much more profit spending those resources on mining bitcoin? And where do you plan to get energy to run that calculation even if you hypothetically had enough performance?

Don't forget that you first need to figure out where the root pw hash starts and ends in the stream of data that you receive from this hack.

Use physical tokens. Passwords is not the future.

Is that an option for the root password on Linux?

Yeah, for example: https://support.yubico.com/hc/en-us/articles/360018695819-Ub...

What would keep a side-channel attacker from reading your YubiKey PIN from kernel memory, and then racing all your authentication attempts until it manages to win the physical button event?

Nothing maybe. But if a side-channel attack gains access to kernel memory, they can do just about anything, and no login scheme is secure against that.