Put simply, jt allows an attacker with a leaked database to use the hashed password as a password. In your original comment, it seemed like you were suggesting hashing only before transmission, on the client; but hashing both before and after would indeed patch that particular vulnerability. I don't know if there are potential problems with that strategy or not.

another approach of client side decryption is to handle decryption completely client site

Here's potentially an opportunity for me to learn: how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it's sending? Since you can't count on a web browser to have the private key, do you send down an encrypted private key that can only be decrypted with the user's password? Is there some other way to do this that I'm not aware of?

[–] RonSijm@programming.dev 2 points 1 year ago* (last edited 1 year ago) (1 children)

In your original comment, it seemed like you were suggesting hashing only before transmission

Ok, that wasn't what I was suggesting, no. That would effectively make your password hash the password itself - and it would kinda be stored in PlainText on the server, if you skip the client auth and send that value to the server directly through the api or something

how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it’s sending? [...] do you send down an encrypted private key that can only be decrypted with the user’s password?

Yes, pretty much. I can't really find a good, detailed explanation from Proton how it exactly works, but LastPass uses the same zero-knowledge encryption approach - which they explained with some diagram here - with a good overview of the client/server separation of it's hashing.

[–] ilinamorato@lemmy.world 1 points 1 year ago

Awesome. Thanks for the links and the info.