Send already hashed password to backend instead of raw password with asp.net identity
Hello. I am trying to build the backend for an app that handles sensitive mental health data. The data is already end-to-end encrypted. The client generates a DEK to encrypt the data with, derives a KEK from the password, and encrypts the DEK with the KEK and submits that to the backend. The project was originally not going to be end-to-end encrypted, so I already implemented the typical username/password flow. The problem is sending the raw password to the backend would allow us to create the KEK and use it to decrypt the DEK and access the users data. I want it to be completely impossible for me to see the users data, so my server needs to never see the users password.
Thanks in advance
20 Replies
Hi! What's the question here?
just trying to figure out the best way to setup asp.net identity in a way where the backend never sees the plain text password i guess
i guess i could just manually hash passwords myself and not use asp.net identity
idk if thats a good idea tho
Idk much about ASP.NET identity but it would be nice if only the client has that password/KEK
Can't you just separate those 2 things?
- Auth (usual username/password for example)
- Encryption/decryption of the data
- Client is encrypting the data
- Client sends the encrypted data to the backend
- Client fetches the encrypted data
- Client decrypts the encrypted data
thats pretty much what its doing right now
but the problem is i want the user to only have 1 password
so if i were malicious, i could intercept their password when they sign in and use that to decrypt the data
this is basically supposed to be
1: insurance for the user that we wont touch their data (because we cant)
2: a way to skirt giving user data to malicious actors via supeonas
3: a way to make data breaches less impactful
these are all pointless if we can just intercept the users password and decrypt the data anyway
Which bascially means that you can't use the same exact password
It has to be different otherwise you always have that key info
yeah, but i dont want them to have an encryption password and an authentication password, i want it to be completely transparent to the user. this should be possible by encrypting the password before sending it and checking it against the hashed password in the database instead of sending the password and hashing it on the server
when the user signs in the password would be used both to authenticate with the server and to generate the KEK so it can decrypt the DEK and access the data
Yeah that should work because it's not the same exact password then
Make sure to generate a hash like
hash(password + salt)
So called salted password hashingye, i wonder if its even worth using asp.net identity at this point tho, like im already manually handling tokens, email verification, etc
No clue, never really worked with it
Would it not work with a hashed password?
It should right?
that was sorta my initial question
Would you be able to hash the password on the client side? (this is a must)
Seems like you can hash the password from within ASP.NET but that's too late
Raw password already reached the backend here
yes
oh wait
are you saying hash the password on the client side, and then just use the hashed password like a plain text password on asp.net?
Yes, that's my current idea
that would probably work. would get encrypted again before storage for no reason but thats not really a problem
Not sure how that fits in with ASP.NET but that's how you usually do it with hashed passwords
seems kinda jank tho. maybe better to just rip out asp.net identity at this point, not sure its doing anything and theres already so many jank work arounds in there to get it to work exactly how i want lol
oh wait a second
i just realized we do want to double-encrypt the passwords
otherwise if our data is breached people could send the pre-hashed passwords to get into accounts
they'd still have to get the original password to decrypt the data tho
Yes
so maybe your idea is the best anyway
i think thats what ill do, thanks
You are welcome! Not storing any key information on the backend is the ultimate goal
Use cryptography packages to encrypt or decrypt passwords or other sensitive informations.