0

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?

8
  • How are you implementing Argon2 client-side? – schroeder Aug 7 '20 at 11:32
  • Are you aware of the available protections against TLS "fake certs"? – schroeder Aug 7 '20 at 11:32
  • Why consider Argon2 when you could use MD5? What does Argon2 get you? – schroeder Aug 7 '20 at 11:33
  • @schroeder I'm using sodium. In regards to fake certs I can always go with cert pinning but with our current infrastructure (and time constraints) it's not viable, maybe in the future. about the MD5 comment: I've always read that MD5 isn't even secure anymore and everybody is recommending Argon2. But I'm not sure how secure it is when used this way, hence the question. – Can Poyrazoğlu Aug 7 '20 at 11:40
  • Argon2 (with salt) will better prevent brute-forcing simple passwords than MD5, when a hash is leaked in transit. It will not be of much help against dictionary attacks. – A. Hersean Aug 7 '20 at 11:51
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.

2
  • I see. The only part is why it might become worse than sending in plaintext. I understand that it might be almost equivalent of sending via plaintext and hash becomes the password, but I don't understand why it can be worse, given that I don't substitute it for some other more secure mechanism. In worst case scenario, isn't it just an extra layer on top of everything else that might at least protect user passwords leaving the device? – Can Poyrazoğlu Aug 7 '20 at 13:47
  • 1
    @CanPoyrazoğlu I completed my answer. I hope it answers your comment. – A. Hersean Aug 7 '20 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.