I'm thinking about a client-side encryption concept where only the client knows the master secret (a user password). A correct implementation assumed, with KDF and authenticated encryption solutions it should be possible to ensure confidentiality and integrity without submitting the secret (from password derived key) to the server and also without saving the secret at the server.

But what is with authorization in this scenario? How can I control access to resources without a "login process" on the server? E.g. how can I prevent that a user deletes a resource from another user?

My only idea is using a CSPRNG to generate a random ID for each resource. But then resource IDs will be turned into sensitive informations, what doesn't seems perfectly reasonable to me.

Are there any strategies/technologies that I am missing? Thank you for pointing me in a new direction.


In short you need a separate authentication mechanism - i.e. the user needs to log into your server some how. Your random ID approach has several issues -

  • As you pointed out these need to be securely stored by the user. You also need to be certain they cannot be intercepted.
  • You have no idea what belongs to who. If a user loses their ID set you have stale documents on your server but no idea which documents are those ones. You also can't restrict users storage space etc.

I'm assuming because you have asked that you do not want users to have to store multiple passwords. Which really leaves three approaches - both of which require a user ID or username for the case where multiple users choose the same password.

  1. On the client side you take a cryptographically secure hash of the users password. This becomes the users authentication password (so you store a hash of the hash on the server). This is fairly simple to implement. In theory it should be secure but passphrase re-use isn't advisable.

  2. The user generates a private/public key pair from the user ID + passphrase (by using a key derivation function to generate the seed to a CSPRNG which is used to generate the private key). You would then generate an entirely random symmetric encryption key, encrypt this with the private key and send both the encrypted symmetric key and asymmetric public key to your server. The private key can be recovered with the passphrase. The application gets the encryption key by requesting the encrypted version from the server and decrypting it with the private key. The user authenticates by signing messages with the private key - and the server can verify them with the public key.

  • Yes your are right, users should not be forced to use multiple passwords. Thank you and @joe for listing the different possibilities that helps to rate my scenario. Both your answers show me that this topic isn't easy to solve and that I'm not overlooking an obvious solution. – Peter83672 Nov 10 '17 at 15:45

You could store a mapping of user information that is associated with each key in a database and do a lookup and set it in an encrypted session cookie that the client can pass back and forth. This of course is an awful solution but it can be implemented. The correct way would be to have a log in mechanism if you need user specific roles. What you are describing is basically how oauth works and it shouldnt be used in instances like this. This type of auh your describing is generally for service to service auth with no restrictions.

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.