What about high-entropy secrets? Is it sufficient to salt and hash them with a normal modern hashing algorithm or should I still use a password-hashing-function to increase calculation time and memory?
Example: User uses a cryptographically secure RNG to generate a 256-bit secret which he then uses as 'password' to sign up. Is it good enough to store a salt and the sha256-hash of the salted password to compare against in the future?
Yes, but in practice you don't know that's what a user did, so you'd run it through a password hashing algorithm anyway.
However, for high-entropy things where you do control the generation (or at least know the process used), it's quite reasonable to use a single iteration of a secure (but fast) hash algorithm, such as SHA2-256 or SHA3-256. You don't even really need to salt it; salting is to defeat rainbow tables and make duplicates look different, but nobody can make a rainbow table for even 128-bit-entropy values, and duplicates are functionally guaranteed to not happen (GUIDs are not quite 128 bits of entropy, in fact). Some examples of things where this is a reasonable approach:
- API keys (essentially passwords but by machines for machines, not intended to be human memorable or even necessarily printable)
- Opaque session tokens
- Refresh tokens (typically paired with JWTs)
- Password reset tokens (typically transmitted in a URL as hex or base64)
- Cryptographic keys (if you're just checking to see if a user-supplied key is correct before using it for a bunch of encryption/decryption)
The reasoning behind this being OK is quite simple. Passwords get extra hashing because they're somewhat predictable; while in theory a reasonable-length password could be hundreds of bits of entropy, in practice it's more like dozens. Making the password hashing a million times as expensive is, in terms of the difficulty of brute-forcing the hash, like making the password have another 20 bits of entropy. BUT: that's still only going to get you from maybe 40ish bits of entropy (if it's a quite good password; less if it isn't) to the equivalent cost of 60ish bits. That's still over a quintillion times less work than trying to brute-force a 128-bit value. Similarly, passwords get salted so that they'll have unique hashes and you can't precompute them, but all that the salt is doing is adding some amount - typically 64-128 bits - of entropy to the password (and then storing that extra entropy in plain text, so it doesn't actually make brute-forcing any harder). A high-entropy (128+ bits of entropy) value already has more entropy than a typical password + a 64 (or plausibly even a 96) bit salt; collisions are just not going to happen, and precomputing is literally impossible because there isn't enough storage on the planet to hold the table, nor enough compute on the planet to generate it.