Is it safe to derive the salt from the users email/phone number when pre-hashing a password to be sent to a server?
I'm working on making an end-to-end encrypted app that will store sensitive mental health information. The goal is to make it completely impossible for someone with access to the server to see the users raw data. The server acts only as a storage vessel for the users account. It should be completely impossible to access the users data without their password.
Currently what my app does when you sign up is the client generates a DEK and uses that to encrypt the data. The app also generates a KEK derived from the users password plus a random salt and uses it to encrypt the DEK and sends that along with the salt to the server. When the user signs in on another device, their encrypted records, KEK salt, and encrypted DEK are sent to the client. The client then uses the KEK salt along with the password to re-generate the KEK and decrypt the DEK, which can then be used to decrypt the data.
The problem is, currently I'm using asp.net identity on the backend to handle issuing tokens. The problem with this is the password is sent to the backend in plain text completely defeating the entire point of this shebang. If a malicious actor, rather that be a hypothetical version of me trying to sell my customers data or an attacker in my server, wanted to access the customer data, they could simply harvest passwords as they come in, pull the KEK salt and encrypted DEK from the database, and follow the same process the client would to access the data.
My idea is to hash the password on the client side, and use that as the users "password" on the backend. asp.net would then hash it again like it does for any other password so an attacker in the database could not later exchange the hash for a token.
The problem is salting the hashed password before it is sent to the server. I can't just randomly generate a salt like I do on the server-side, because then when the user signs in from another device, that device won't know what the salt was and won't be able to regenerate the hash. I can't derive the salt from the password because then they would not be unique per account if 2 accounts had the same password. So my idea was to derive the salt from the email using a KDF. If the user ever changes their email, the client could just also provide an updated password hash and already authenticated devices would be unaffected since they already have tokens.
I don't want the user to have a second encryption password on top of the authentication password. I am certain this flow is somehow possible to do securely, as services like bitwarden and firefox do it.
Thanks in advance
