Hacker News Reader

Comment by cvoss | Hacker News Reader

> According to our friend Chick3nman, the same RTX 5090 can crack 4.18 billion (with a “b”) of these hashes every second.

It may just be imprecise writing, but this is very misleading. The stat is that 4.18 B hashes can be computed per second, not cracked. Computing a hash means converting a given input into its hash. Cracking a hash means starting from the given hash and determining what the input must have been. To crack a given hash you have to iterate over the input space and compute all their hashes (barring other exploitable weaknesses).

So, sure you can "crack" 4.18 B hashes per second, as long as you don't care that the hashes you are "cracking" are not the one you're interested in.

View on HN

As a pentester kerberosting used to reveal a service password on about 50% of networks on the 2010s when admins were making the passwords. Today our advice to clients on kerberosting is the same as it was back then, use a password manager to generate a 21 character password for all service accounts and disabled RC4 where possible. 52^21 is quite a large key space and even at 10^10 guesses per second over a year your chances are less than 1 in a billion of a successful crack.

> disabled RC4 where possible

I'm curious. Under what circumstances would it be _not_ possible to disable RC4?

Is this in case there is a Windows 98 machine running somewhere in the network?

In my experience it's always been legacy hardware or industrial automation where it would cost millions to update the equipment / software. Simply limiting the blast radius of those systems and isolating them on the network into their own security zone is always less expensive and thus the perfectly reasonable solution.

Cheap Cloud storage has never returned rainbow tables to viability, right? I stopped checking sometime after I got out of the space.

salting defeats the rainbow table, kerberos uses PBKDF2 that defeats the rainbows

Good point, it's computing not cracking.

I will make a slight subtle distinction though. Cracking a hash doesn't mean determining what the input must have been. It means finding an input that resolves to the same hash - not necessarily the original input.

Not sure why this is downvoted, as hash collisions can happen, even if unlikely.

Due to the pigeonhole principle they are inevitable. At least if the input space is bigger than the output, which may not be the case for passwords of course.

Still, even if they are shorter, if you do find a hash pre-image you don't actually know for absolute certain that what you found was the original input. Collisions are still possible.

In practical terms this doesn't really matter mostly. It's just good to be very clear about what you actually know when dealing with cryptography.

Given that a collision is technically what they're looking for.

They're just limiting the input to a "reasonable" range to find one faster.

Side note: A quick look through the iOS keyboard shows another 25+ characters that can be reasonably expected to match between operating systems. I need to try using some of them in my passwords. Going from 70^(length) to 100^(Length) is nothing to scoff at.

Reply on news.ycombinator.com