This is great. Seems a lot of people, including me, are thinking about the same problem.
Maybe it's my lack of understanding, but I would like to ask: where does decryption happen? Since you keep the private key passphrase encrypted, I would assume this happens on the server side. Does it mean that when data needs to be accessed by the user you get the password from the request, here assuming you are not keeping the user password plain text, then decrypt the data and send it back. What I'm trying to understand is: can the system owner alter the system to gain access to the user's data?
What I was thinking about is to keep the private key passphrase encrypted within the client app ( + mailing it as a backup) and provide the user with ability/instructions to transfer the private key, between clients/browsers. So, essentially the server keeps only encrypted data, the client handles decryption, etc. This still doesn't guarantee 100% privacy, i.e. as a service owner I can alter the client to send the data I want to the server.
Anyway thanks for the post, it gave me a different perspective to think about.
Yes, it does happen on the server, and then the result of decryption (private data) is stored in the encrypted session that is available only when the client communicates with the backend.
Of course, as the owner of the system, I can always modify it to eventually get access to anything (when the user finally logs in).
I would be violating my own terms of service and privacy policy though by doing that and will be liable for this. And I don’t want that kind of liability on my shoulders.
Now, the client-side encryption is awesome! Especially, if you are dealing with power users or niche, where folks will overcome the initial UX struggles to start using the authentication key like this. In fact, certain bank systems allow you to log in only if you use a separate private key file on a special crypto-device that you have to connect to your computer.
And for banks or other crucial systems, and especially in B2B and for enterprises, that might work.
For the B2C software that’s going to be a huge block preventing people from using your product, unfortunately… Especially, if the product, like FelloWage, relies on a lot of user sign-ups and data shared before it becomes valuable for other users.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is great. Seems a lot of people, including me, are thinking about the same problem.
Maybe it's my lack of understanding, but I would like to ask: where does decryption happen? Since you keep the private key passphrase encrypted, I would assume this happens on the server side. Does it mean that when data needs to be accessed by the user you get the password from the request, here assuming you are not keeping the user password plain text, then decrypt the data and send it back. What I'm trying to understand is: can the system owner alter the system to gain access to the user's data?
What I was thinking about is to keep the private key passphrase encrypted within the client app ( + mailing it as a backup) and provide the user with ability/instructions to transfer the private key, between clients/browsers. So, essentially the server keeps only encrypted data, the client handles decryption, etc. This still doesn't guarantee 100% privacy, i.e. as a service owner I can alter the client to send the data I want to the server.
Anyway thanks for the post, it gave me a different perspective to think about.
Yes, it does happen on the server, and then the result of decryption (private data) is stored in the encrypted session that is available only when the client communicates with the backend.
Of course, as the owner of the system, I can always modify it to eventually get access to anything (when the user finally logs in).
I would be violating my own terms of service and privacy policy though by doing that and will be liable for this. And I don’t want that kind of liability on my shoulders.
Now, the client-side encryption is awesome! Especially, if you are dealing with power users or niche, where folks will overcome the initial UX struggles to start using the authentication key like this. In fact, certain bank systems allow you to log in only if you use a separate private key file on a special crypto-device that you have to connect to your computer.
And for banks or other crucial systems, and especially in B2B and for enterprises, that might work.
For the B2C software that’s going to be a huge block preventing people from using your product, unfortunately… Especially, if the product, like FelloWage, relies on a lot of user sign-ups and data shared before it becomes valuable for other users.