SHA-256 is still secure for plenty of applications, but for awhile it's been regarded as a suboptimal choice for password hashing. SHA512 is probably overkill.
Algorithms designed for password hashing are intentionally both compute and memory intensive, to make guessing slower, whereas general cryptographic hash functions are by contrast intended to be fast, as most applications will want that. The idea is that password hashing algorithms should be fast enough to keep up with a human and no faster; if you already know he password the performance is not a hindrance but if you have to guess it makes doing so impractical.
SHA256, SHA512 and Blake* algorithms are suitable for secure checksums and HMACs, but not password hashing
> argon2
It uses BLAKE2 internally
> I also see no benefit to that approach
- less primitives
- faster
- less memory usage
- no concern regarding cycles
Anyways, most people don't use high entropy passwords, so there's little point in arguing against this IMHO.
Good luck brute-forcing through 2^256 passwords. The speed of the hash function should not matter.
If you still want a slow hash function though then just use more rounds.
> The only thing protecting your high entropy password is the cost of the hash
No, not really. It is the fact that the password is high entropy, combined with the preimage resistance of the hash.
> If you could run infinite attempts in 2 seconds then even your high entropy password would fail.
So would your pkdf.