[Feature] Hash password on the client side

[Tweakified]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Thanks for the great application guys.

Thought of a feature request which I thought would be cool.
I noticed that the user's password is transmitted in plain text to the api/auth/login endpoint. To improve security, especially over less secure networks, it might be beneficial to hash the password client-side before sending it to the server.

Platform

• Server
• Web
• Mobile

[bo0tzz]

This is a common misconception about handling passwords. If you hash the password clientside, in effect that hash now becomes the password as far as the server is concerned, and any interception still has the same end result. If you're worried about MITM attacks, you should use HTTPS.

[Tweakified]

Hiya, I understand the server would utilise the hash as the password however I still think it would be a useful security feature, particularly in the event the user is reusing their Immich password for other services which is very common.
Implementing this feature would result in MITM attacks not being effective in this scenario.

[bo0tzz]

would result in MITM attacks not being effective in this scenario.

This is part of the misconception; MITM would still be effective, as the attacker can just send the captured hash to the server, which treats it just like a plaintext password.

in the event the user is reusing their Immich password for other services

This isn't something that can be solved with application level measures like clientside hashing.

[Tweakified]

Sorry I wasn't very clear. I agree with you that even with hashing the password, the MTIM would still work on immich, allowing malicious actors to intercept the traffic and provide the same hash to the immich server. However, what I'm saying is the MITM wouldn't be effective on logging onto other services (not immich) where users might have used the same password.

[danieldietzler]

Where's the point though. For one thing using the same password comes with many more downsides (such people are likely to use guessable passwords anyways, rainbow tables are a thing.), but also using TLS just solves all those problems. TLS is the actual solution to the problem you're describing, why should we implement something with (nearly) zero benefit that's just a worse "solution" to a problem?

[Tweakified]

I was mainly thinking about rare edge cases like if a malicious root CA was installed. In that case, client side hashing might help limit damage if someone reused a password elsewhere. But I get that TLS is the right answer in almost all scenarios, and I understand why this was closed.
Appreciate the discussion, and thanks again for the app! I’ve been using it a lot, and it’s been awesome.