[codefined]

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?

[lostcolony]

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.

[marcosdumay]

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.