A WebService which stores user Data and a server with a database.

A Administrator which can acces the sever wit hthe webservice and the server with the database.

Foreach user is a dedicated database.


Store the data in a way so that even not the administrator can access it with the secret of the user.


To make sure that the Administrator can't access the data stored by many users the data can be encrypted with a user secret. and / or the database can be created with a derivation of the user secret as password.

The data can then be decrypted on the client side.


This works with common user logins so I could use the user password or a hash of it as database password / Encryption. But Is there a practice what to do if the user authenticates with a external oAuth Login (Google,Facebook,Github...)? In this case i don't have any secrets / password of the user.

For me it would feel a little awkward to ask him for a "MasterKey". Are there any experiences on this scenario or real world examples?

  • The only way to make the data unavailable to the system's administrators is to encrypt it locally before uploading it. This is certainly not common practice as all it'll allow you to manage on the server is data storage. If you can not rely on your system administrators, you should replace them. Jul 25, 2016 at 15:00
  • @JuliePelletier: this is not always a matter of trust.You may have business or legal requirements to ensure that nobody but the owner of that data can access it.
    – WoJ
    Jul 25, 2016 at 15:23
  • What happens if the user forgets their password? You content having them lose all their data? Jul 25, 2016 at 15:53

3 Answers 3


The rule is that if the data is in clear text at any moment on a machine it is accessible to the admin of the machine. Because by definition, an admin can use administrative tools and can read memory of any process or install spys on any network route.

Doing so without good reason is of course a professional fault and the admin can be fired for that, not speaking of legal actions, but technically it can be done.

The only thing that could be done here would be to have different administrative zones, and configure the system so that the database machine admins cannot access the data. For that, the main server should be distinct from the database server and the database should only contain encrypted data. It can make sense if you have an internal server but want to store the database externally for redundancy reasons. But a much more common use case would be to have an internal database, and only store encrypted dumps in the cloud.

TL/DR: if you cannot trust the admin, you cannot trust the machine, so the webservice should only process encrypted data, which means that you need something else and elsewhere to actually process, encrypt and decrypt the data.


For me it would feel a little awkward to ask him for a "MasterKey".

It does not if the core of the service is to ensure that only that person can access the data by first decoding them.

The authentication via an third party is in that case is not useful, you will be better off handing it (correctly) yourself so that the users have only one authentication process to go through.


The obvious problem with your model is that you need to load and decrypt every record if you want to search a database. It's not going to scale.

As to the problem of managing the secret, store it on the browser, e.g. in a cookie - my encrypting session handler does this - the session id is not encrypted and is the only key used to look up the data, hence there is no problem with indexing. You can generate an initial value and advise the user to take a copy and store it securely (in case they lose the copy in the cookie) then provide a means for them to enter the value later.

I disagree with WoJ about implementing your own authentication. Most of the large providers employ a lot of smart people and can justify spending the time developing and testing secure mechanisms for managing accounts - and with the data encrypted using a token the third party has no access to you have less to worry about in terms of the authentication provider acting as an adversary.

  • It isn't necessarily the case that searching the database would be impossible in this scenario. If the encryption algorithm is deterministic - i.e., using the same input values will always give the same output - then encrypting the search term and matching on the encrypted value is a possibility. Doesn't work for substring matches, of course, and also doesn't protect against known plaintext attacks, but sometimes that's perfectly acceptable. Nov 23, 2016 at 7:24
  • It doesn't work for anything which is not an atomic equivalence i.e.partial matches and range matches.
    – symcbean
    Nov 23, 2016 at 9:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .