Hacker News Reader

Comment by hoppla | Hacker News Reader

Is anyone still using rainbow tables? I have not heard much of it since GPU cracking

Rainbow tables don't make sense for a salted hash. So you're immediately narrowing down to only cases where an unsalted hash is used, like Microsoft's NTLM system or some older web systems that do MD5(password) or similar.

Building a rainbow tables is much more expensive (compute time, storage) than just breaking any individual hash. So unless you break hashes all day every day, you probably need to share that expense somehow, but then you can't customize. Maybe a large group of you want all of the old "NT hash" values, that's easy enough, but agreeing to do 5-7 alphanumerics for MD5() means the person attacking a site with an eight character minimum gets nothing out of it.

So aside from things like NT hash it has fallen out of favour.

Rainbow tables can still make sense for a salted hash if the salt can be predicted. A current real-world example I just recently learned about: SSIDs (network names) are used to salt WPA-based WiFi network password hashes. If the SSID is a default name (examples: NETGEAR, LINKSYS, XFINITY, etc.), then you could use a rainbow table.

The salt is defined to be random. To the extent you shove something that isn't random in as "salt" you don't get the desired consequences.

And I think ISP hand out WiFi routers stopped having daft names like this a decade or more ago. The only AP SSIDs that aren't partly random nonsense I see around here are my own (named "Reformed Distributed Republic") and somebody's FON router, the main ones I've seen elsewhere in my city are "eduroam" and "govroam" which are federated systems and so do not have a PSK - in all four cases you aren't going to help yourself by calculating rainbow tables with those SSIDs.

I've definitely still seen several in-use private WiFi networks using "NETGEAR" (although they usually have 2 numbers appended to the end, so that expands the keyspace by 10^2 = 100 different rainbow tables to crack those hashes).

It looks like this generic, repeated-SSID-naming "vulnerability" might continue into the present day via the use of a default name on hotspot devices, or smartphones serving as hotspots -- notice that on the "top 25 pwned wifi network names in the @pwnagotchi project database"[1], the top 1st and 2nd place respectively go to "AndroidAP" and "iPhone". Looking at my Pixel 3, I notice that the default hotspot name doesn't appear to be randomized (it's "PixNet").

[1]: https://twitter.com/evilsocket/status/1305892201222807552

Whatever you can do online with a GPU, you can do much in an offline session stored in a file.

Sharing rainbow tables over the internet is probably dead, but your disks can keep more hashes than you can calculate quickly.

A new GPU is able to calculate ~50,000 million MD5 hashes per second, an MD5 hash is stored typically on a 32 bytes hex string. If you want to store that you'll need more than 1TB per second: https://gist.github.com/Chick3nman/bb22b28ec4ddec0cb5f59df97...

I used MD5 because that's the typical hash you find unsalted on leaks, but if you do the math with others it is almost impossible to find an example where storing beats using a GPU to crack (even an older one) for a couple of hours.

Are there any archaic hashes that are built to be "slow" where this might not apply? It feels like a lot of modern slow hashes have salts built in (e.g. Bcrypt, Scrypt, Argon2) but if one didn't use a salt it would definitely still make sense to use a rainbow table against these hashes.

Is the idea that password hashes should be slow relatively new?

No, the idea that password hashing should be slow is built into the basic understanding of what password hashing is for and should do.

It's just that security wasn't as important (limited web attack surface) or generally understood back in the day (so people were even less likely to ask "is this hash suitable for passwords rather than checksums/indexing/etc?" than they are today), or the slow ones from then were fine -then-, but advances in hardware, the availability of the cloud/GPUs (so massive parallelization without a cost of infrastructure only a nation state could afford), etc, means they're easily compromised today.

The GP is correct, and I made some mistake on my estimation.

The idea that password hashes should be slow is indeed relatively new. Also it's contemporary to the idea that algorithms should have salts builtin, so those features usually go together.

Reply on news.ycombinator.com