I want to know if it ever makes sense to hash a password client side and rehash it again on the back end. I've not seen this done before which makes me suspicious as to whether it really does add security. Here are the threats I'm considering:
- The server operator could be evil and watches incoming plaintext passwords. If the incoming passwords are used elsewhere the evil operator gains an advantage against the user. Let's assume the user is able to verify how passwords are being sent from the client - so the evil server can't easily backdoor the client login.
- The client side hashing algorithm is implemented poorly. Perhaps we have a open api and a developer implements a bad hashing implementation or the iterations is set rather low for performance reasons. The server is hacked and the insecure hashes are leaked.
Potential implementation:
- Client requests from server a user's publicly known alg/salt/iteration. Without this we can't ever "upgrade" the password hash.
- Client hashes the password and sends an authentication request
- Server accepts the hash. Hashes it again the same way it would hash any plaintext password. Checks if the hashes match.
Use cases:
- Providing trust to users.
- Services that encrypt all data client side and wish to claim client data is not accessible to operator. (Password managers, file sync services, email providers, ect)
- Defending against future possibilities such as government intervention or blackmail. This is only helpful against knowing passwords as they come in and hoping the user reuses passwords.
