SecureData even for admins with external login

Question

Given:

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.

Aim:

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

Thoughts:

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.

Question:

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.