[Intermernet]

A step in the right direction is to use encrypted backend data / databases. This is still fraught with problems, but it provides another layer of protection and can demonstrate the difference between "The data was just sitting there" and "We had to manually exfiltrate the encryption keys to read the data".

It's not perfect, but it adds another layer to prove malicious intent.

[mike_d]

In the vast majority of situations where I have seen unauthorized use of data in this fashion it was customer support people. All the encryption in the world doesn't help if you build tools that allow relatively low paid and under-trained employees to access the data at will.

Effective things you can do to reduce risk:

  - Deploy honeypot accounts that email multiple people if they are accessed
  - Create a two-man system that requires a second person to approve "risky" things
  - Require a 2FA token for your internal tools
  - Email the user when they log in from a new IP address
  - Have support staff use two different browsers - one to access the ticket system and another to access internal tools

[jasfi]

I've thought about this, and researched it too, and see two problems with encrypting user data in the DB:

  1. You would have to use an external search engine to index user data, and that would need encryption too.
  2. If the user forgets their password then their data is inaccessible.

There are ways around 2, but the most obvious way is to encrypt the password with answers to 3 common but difficult to know questions.

[arduinomancer]

The encryption key doesn’t have to be per-user.

If your data is stored in a 3rd party database its common to just use one secret key (which only your app has access to) for all the data to prevent the 3rd party from reading it.