If you’re going to do this, make sure you still hash the client’s hash output on the server (you can use SHA-2 in this case since the client’s hash output will effectively be high-entropy if salted). Otherwise you will be vulnerable to a “pass the hash” attack where an attacker in possession of your stored password hashes simply passes the hash to login.
It's important to understand why this is so: it's because the hash is big, so while it might be possible to mount a brute force preimage attack against a password, it is not practical to do so against a hash. So hashing a hash (once) is secure even though hashing a password (once) isn't.
Almost. That construction is still vulnerable to chosen input attacks without inner and outer padding, which is basically rediscovering HMAC, which also isn’t suitable for storing passwords. Don’t roll your own crypto if you don’t know what you’re doing. Use a PBKDF like argon2, scrypt, bcrypt or PBKDF2 as they are intended because they are far, far stronger than hashing a couple of times.
I believe what we’re discussing is having a client compute a PBKDF of the password, and then having the server hash the PBKDF output one more time to obtain the thing that’s actually inserted into the database. The idea is that if the database leaks, the attacker gets H(PBKDF(password)) which is hard to bruteforce due to the PBKDF, and can’t be used directly as a login token because of the extra H(). I don’t see where this would be subject to a chosen input attack.
