0

Normally I would want to develop an app that encrypts user's data with symmetric encryption (AES 256) from a password based derived key (PBKDF2).

For a new project, I would like the users to be able to add data to their account without authenticating. All they would have to know is their account identifier (username, email, etc).

Could I accomplish this with asymmetric encryption like RSA? Unauthenticated input would be encrypted with an account's public key, and only the account holder could decrypt with their private key.

Would this be an acceptable approach, or am I totally off?

Edit: To clarify, a use case would be the ability for the system itself to generate data on a user's behalf that can only be decrypted by the user. Assumption that the system makes no logs of this.

  • Unauthenticated means "I don't know who did that", not "I didn't need to log in". You could certainly encrypt things with a user-specific public key, except: 1) If unauthenticated users can write to the datastore, they can't trust the data inside - you've just re-invented PGP-mail, essentially. 2) Most users can't handle a private key, so it immediately raises the question of "who is doing decrypting?". If it's (one of) your services, why are you bothering? You're in control of the database... just write to it normally. – Clockwork-Muse Nov 22 '18 at 0:31
  • @Clockwork-Muse, the goal is for the service to never have user data in plaintext at rest. The user's private key is only accessible by their password authentication, and will decrypt data client-side. The public key will be known by the service to encrypt any data being "dropped" into the target user's account. – Sterling Beason Nov 22 '18 at 0:46
  • In almost all cases, at-rest encryption is best accomplished via encrypting the database/filesystem (because that's a built-in feature). That only covers out-of-process attacks, though (SQL injection usually still works, for example). Decrypt-on-demand is usually done with a symmetric key (protected by the password), and on the server - unless you have an external app that registers a public key on creation, you have to distribute the key with the decrypting code, so that doesn't gain you extra security. – Clockwork-Muse Nov 22 '18 at 7:44
  • You haven't said what "user data" might be showing up this way, though. That the user isn't creating it themselves is rather strange (the key would be available at that point) - this implies that it's of interest to the business, not the user, so you'd want a non-user key protecting it. What is this data? Where is it coming from? What are you using it for? – Clockwork-Muse Nov 22 '18 at 7:49
0

I think that your users should be authenticated for adding data into their accounts. Take into account that if somebody could polute the data just by knowing the credentials.

Another approach that you can follow is that your application only will write the user data if has been signed properly. On the creation of the account you store the public key of the user and for adding data to that account only data that has been signed with the privake key that your application can verify. Here is an example:

  1. User generates a private and public keys.
  2. Your application generates an account with (username, email, public key) (account1)
  3. Some user wants to write data on account1.
  4. Your application verifies that the data received has a signature that can be verified with the public key of account1. If this operation is true this means that the data received has been signed with the private key of account1, in any other case you reject the data.

Hope these helps you

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.