Once a user have their new password hash stored in the DB, the old md5 wouldn't be used anymore.

That's possible to do with the plan I sent above, if we accept submissions from old clients. However, there is an issue with this.

Let's suppose we want to implement this, so it's possible to use the md5 to login with old clients until the new hash is stored. We'll need a way to keep track of whether the hash has been updated (either with a hashmethod field, or your method of having two password fields, though I would argue the former is a cleaner, more future proof solution). If the hash has been updated fully, then we need to reject the client's request to log in, because there is no longer any way we can validate the md5 the old client sends. If the server stored hash hasn't been updated, we would need to now check the hash sent by the client, before knowing whether it matches.

Now, theoretically, there would be two ways an old clients submission request can fail: either the account no longer uses md5, so the request is outright rejected, or the account still uses it but the password is incorrect. The problem lies in how to handle these two errors.

Option 1 is that the error can explain fully why the login failed. However, this would allow an attacker to figure out if an account still uses md5 (and therefore if it is vulnerable) simply by sending a request with the md5 and seeing if it is rejected completely or if it says the password is wrong.
The other option is to not be specific about which situation occured, however, then, a genuine user won't know if their login failed bc they are using an outdated client or because they actually got their password wrong. Also, an attacker might still be able to tell which case it is based on the time taken to receive a response from the server.

We can avoid this problem by disabling submissions from old clients immediately, and that also gives us the freedom to implement a proper solution and not have to carry around a legacy field in the remoting api. So I do think doing that is the best solution.

Letting the server able to read raw passwords is a bad idea.

It doesn't really make a difference if the server receives a hashed password or the plain password. If the server is compromised in this way, even if the password is hashed on the client, then the bad actor could as well see the hash, which essentially acts as the password itself, and knowing the hash is enough to give them access to the account (using a custom client). Note that the password would still be hashed before being stored anywhere long term. Also, for the client to hash the password, there would have to be public access to any user's salt, which otherwise would be private apart from in the case of a database leak.

Client-side hashing is not a standard practice, and overall it leads to much worse security than server side hashing:

Uh oh!

Stop using MD5 for passwords #314

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions