Set a hash, login with a password?

Question

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?

Answer 1

I agree with @Xiong Chiamiov, there isn't anything inherently wrong with this approach.

On the other hand, it doesn't provide much benefit to the standard approach (all hashing is done server-side), and there is definitely some risk in disclosing the hash to untrusted entities.

If the original client isn't trusted, this obviously does nothing, as the client could just log the entered password.

If the original connection between client and server isn't trusted, this only helps a little. A passive man in the middle still gained the hash and can try to crack it. An active man in the middle could change the hash to gain access, or could change the reply to the hashing policy to force a weak hash to gain the password (or force no hashing at all; or just inject Javascript or similar to read out the entered password).

So the only sensible use-case is limited mitigation against a passive man in the middle on initial signup. If I would encounter this, I would check how untrusted the initial signup really is, and if there isn't a more sensible approach than disclosing the hash.

Answer 2

The issue that usually comes up when talking about client-side hashing is that an attacker who has breached the database can merely pass the hashes to the server to authenticate. However, this scheme doesn't allow use of the hash for authentication, just the initial account creation, so it doesn't fall into that trap.

I've seen this sort of thing used in the context of Apache htpasswd files; users generate a digest and send it on a relatively insecure channel (e.g. email) to the systems administrator, who then adds it to the server configuration. While a system involving basic or digest auth isn't the pinnacle of computer security, this shows that it's not an entirely novel approach, and has had at least some attention.

Given the description as you put it, I don't see any obvious issues. There can of course be implementation issues, like a bug that allows feeding the hash instead of the password for authentication. And since the initial connection isn't trusted, it's probably a bit easier for an attacker to obtain a password hash (that they can then try to crack or generate a collision for). But those aren't issues with the scheme itself, or major issues.

Answer 3

Two nits

possibly after requesting the hashing policy - salt, which hash function, etc - from the server

I am not clear if this mechanism uses a per-user salt or a global salt. If it uses a global salt, it is vulnerable to a rainbow attack.

Server stores "99476bb..." in the database as the password hash for that user.

Because the hash was generated outside of the server, there is no way for the server to enforce any password complexity or length rules. They would have to be enforced by the app. Also, there is no way to check for password re-use.

Answer 4

I don't think the proposed scheme adds any additional risk, but I'm not sure it is actually reducing any either. There seems to be one bit of crucial information missing. Under this scheme, how do you initially vet the client to know they are who you think they are before you allow them to set the hash? This is the real challenge - there are a number of different ways you can communicate a password set/change over the wire to prevent MitM attacks, but when you want to allow remote setup of any form of authentication process, the issue is in vetting the remote user.

I'm also not convinced the policy which is causing you to have to consider this alternative is of any real benefit except to make auditors feel better. Lets face it, if your risk is harvesting of password information from OS memory, the real problem is adequate controls over access to the OS and that memory, not what is in the memory. If someone has that level of access, then they can likely compromise your base authentication process anyway. All the policy is really doing is adding complexity, which will likely create other problems.