How to protect a system from inside (like inside job)?

Question

I have an application deployed in a popular web hosting service. Because they have admin privilege to their machines, I feel that there is an urgency for me to protect my data across all layers, including the database itself.

On the database I am thinking of encrypting sensitive information like usernames and emails, and may be their phone numbers, etc. The repository layer will handle all encoding/decoding requirements.

I have three DLLs: 1) the application layer (controllers and views), 2) business layer (service logic) and 3) data layer (repository).

Normally, users from the outside will request a page and if they are not yet authenticated they will be redirected to the Login Page, typical Form-Authentication stuff. That protects the system from unprivileged users from the outside.

However, in the inside, technically those DLLs can be imported to any .NET application. In which case that application can have ready access to the internal workings of the system.

Answer 1

If the data is hosted on a machine that someone else has administrator access to, you cannot ultimately protect your data and still have access to it. Any encryption you use will rely on a secret, but you will have to store the secret on the box, at which point the owners of the box will have access to it.

The only way this could work is if your users encrypted their data locally before uploading, and then your server served up this same encrypted data back to them. But at that point, you would have no ability to do anything with that data at the server end.

You need to look at the server provider's policy on what they do with data you store on their servers and ask:

1. Do they guarantee not to look at the data?
2. Do you trust them to follow this policy?
3. Do you trust them to be competent at keeping their servers secure from intrusion?
4. Will they have to give up their data to someone else, despite their policy, because of legal reasons? For example, various governments can make companies disclose data.

You can then weigh up the risks and decide whether:

1. You are happy with the risks and still want to store sensitive data with them.
2. Whether your users will be happy with the risks - you will need to clearly communicate your own privacy policy and risks to them so they can make an informed choice.

Also, think about whether you need to store all that information. Why do you need phone numbers? If it is for, say, processing payments, you can hand all of that off to a trusted third party, for example Visa or Paypal. Then they can deal with storing your users' data securely, and you don't have to deal with the risk.

Answer 2

A good practice is to not encrypt and store passwords in the database. You should hash them with a random salt (use the cryptographic RandomNumberGenerator class, not the mathematical Random class) against rainbow table attacks and only store the hashes and salts. Whoever gets hold of that table will still have a hard time impersonating a legit user. Don't even think to store credit card information if you can't trust the DBA. Some web services allow for payment to get across without you ever knowing any sensible credentials, like PayPal redirection and similar. Other sensible data (e-mails) should be encrypted with other user-level data, like the username and a constant salt, like this: "[email protected]+username+AayRUIOH283uID".

All of these are just tiny things that make your life very harder but an untrusted admin's life too. Also consider accepting intranet connections only from your own cloud cluster (trusted IP table), using SSL even between your own nodes and signing assembly files with asymmetric keys, so that a DLL cannot be substituted.

Still, ALL of this is a huge expense of time and effort for a questionable security advantage. As with all aspects, security is not a feature of a system but a compromise of cost/benefits.

The best option is to steer clear of ominous choices, finding alternative less risky solutions (like NOT storing passwords at all). And remember there are tools to tamper binary files (DLL), to inspect release-built MSIML code (compiled .NET like C# even when without debug symbol tables) and tools to tamper with memory while the app is running. There are techniques to make memory tampering very costly, like not storing sensible data (like passwords) in strings but streaming them in a single character at a time in a pinned memory location and overwriting that same character each time, recombining the hash in-place "on the fly" with an incremental hashing algorithm (SHA-256 would be good).

Still, you can't really protect yourself against all kinds of attacks when an admin is untrusted. He'll always be able to switch off your machine physically and take it home to have some fun-time in his basement...