I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.
The scheme for an account creation / password reset goes like this:
1) User types password
"FuzzyCat"into a client-side app.
2) Client-side app hashes the password
hash("FuzzyCat") -> "99476bb..."(possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.
3) Server stores
"99476bb..."in the database as the password hash for that user.
4) When the user comes to log in next, they enter
"FuzzyCat", the server hashes it and compares it to
"99476bb..."in the database.
The use-case where I saw this is that accounts are initially created by an automation script as part of a several hour bulk process, and we would rather not have the plaintext passwords floating around in memory / on disk during that time. All subsequent logins by the user will be directly to the service over a secure channel (note: not
https, I mean "sign the logbook to get physical access to the room" type of secure channel).
To address comments, the reason we don't trust the automation script is that it is written in a language with immutable strings and garbage collection, so any memory containing passwords will be returned to the OS un-zeroized - which does not meet our internal policies for password handling. So yes, the main concern is a passive MitM.
Question: What possible vulnerabilities / problems might there be with this scheme?
The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach.
As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?