Is using Argon2 with a public random on client side a good idea to protect passwords in transit?

Question

Not sure if things belongs in Crypto SE or here but anyway:

I'm building an app and I'm trying to decide whatever is secure to protect user passwords in transit, in addition to TLS we already have.

In server side, we already have bcrypt properly implemented and takes the password as an opaque string, salts and peppers it, and compares/adds to the database.

Even though SSL is deemed secure, I want to stay at the "server never sees plaintext" and "prevent MiTM eavesdropping from sniffing plaintext passwords" side of things. I know this approach doesn't change anything about authenticating, anyone with whatever hash they sniff can still login, my concern is to protect users' plaintext passwords before leaving their device.

I think Argon2 is the go-to option here normally but I can't have a salt with this approach. If I have a random salt at client side that changes every time I hash my plaintext password, because my server just accepts the password as an opaque string, I can't authenticate. Because of my requirements, I can't have a deterministic "salt" (not sure if that can even be called a salt in this case) either (e.g. if I used user ID, I don't have it while registering, I can't use username or email either because there are places that I don't have access to them while resetting password etc.) so my only option is using a static key baked into the client. I'm not after security by obscurity by baking a key into the client, I'm just trying to make it harder for an attacker to utilize a hash table for plain text passwords. I think it's still a better practice than sending the password in plaintext or using no "salt" at all, but I'm not sure.

Bottomline: Compared to sending passwords in plaintext (which is sent over TLS anyway but to mitigate against server seeing plaintext passwords and against MiTM with fake certificates), is that okay to use Argon2 with a public but random value as "salt" to hash passwords, to protect user passwords in transit? Or am I doing something terribly wrong?

Answer 1

Argon2 is not meant to protect anything against MITM. It's not the right tool for the job. Using Argon2 on the client side (with or without TLS) will force you to either store the plaintext password on the server side, or it will make the hash become the password: in both cases you end up usually worse than when sending the plaintext password over TLS.

You might need to think more about your threat model.

Extended answer:

A "solution" can be worse when you look at your overall information system, and not just on one threat. An extra layer that does not significantly improves security might needlessly increase the complexity of the system, the chances of bugs to happen and the number of interfaces an attacker could try to exploit, thus decreasing the overall security of the system.

In your case, if your hash becomes the password, and you save this hash in the database, it is as bad as saving plaintext password in the database; especially since you are assuming an attacker able to do MITM in TLS, who should be able to replay the hash to authenticate. If you are not assuming that an attacker can have this capability, you do not need this extra layer of protection.