[RyanZAG]

I'd say the first thing to understand here is that absolute safety is impossible in this case. If the hosting server is compromised, password loggers can be installed and even the login page itself can be altered to remove any form of security. With access to emails, an attacker could send an official email asking everyone to reset their passwords, etc.

So your question is actually: How can I make my system divulge the least amount of data as possible over time to someone who has compromised the service?

To hamper someone from changing your service to remove security you could set up daily checks from a server hosted in a different location to download your static resources and check them against a pre-validated hash.

For storing data - as others have mentioned - the key is to store that data in a way that it cannot be accessed from that one server alone. A simple solution for this is to setup an internal service that will provide the data when given the correct login details. This gives the attacker an additional server he would need to hack. If you keep this layer as simple as possible it can add a lot of security. Of coarse, if the hacker is able to compromise your server for a long period, he can record anything passing through here anyway.

In the end though, the web-server itself is a lynchpin in which all customer data has to flow at some point, and if that key server is compromised for a long enough period, eventually all data can be extracted regardless of precautions. That means that designing your web service with security in mind from day 1 is very important. Regardless of what people try to sell you here, there are no silver bullets that will prevent data theft - only mitigate the impact or delay it.

[patio11]

This gives the attacker an additional server he would need to hack.

If they root your web tier, and your web tier knows how to ask your internal service layer for sensitive data, then the attacker knows how to ask your internal service layer for sensitive data.

I really hate repeating "If you lose any one box in your deployment then you can assume you will lose all data, regardless of whether you encrypt things or not" because it makes me feel like Debbie Downer, but that is, in fact, the threat environment.

[RyanZAG]

If you don't store your user passwords/hashes in a way that your web layer can access directly, then you can slow the attacker down by requiring them to wait for that user to actually log in and send the password. ie. If your web layer passes the authentication tokens through to the data layer, and the data layer handles storage/authentication of those tokens, then hacking the web layer only allows you to log future requests.

To achieve a layout such as this, you would prevent your web layer from talking to the database itself directly, and force all data requests through a different service layer.

Obviously, this makes your whole architecture much more complicated and you only really gain any security if you are able to detect the attacker before he can sniff all passing user data anyway.

Your assumption is still spot on though - one box down really does mean game over. All of the tactics above and in the rest of this thread only slow down an attacker or make the attack more complicated. None of them will ever prevent it entirely.

[ProblemFactory]

While this is true in theory, compartmentalizing services and data can add security in practice. Attackers may not know the details your internal systems, and any unusual behaviour helps with detecting intrusions.

* For example, if credit card details are stored on a separate service, then the web tier can be given only a "charge the card" API, instead of a full read access.

* Even if the decryption key is held in memory, encrypting the data on disk helps against accidental leaking of backups, physical theft of the servers. Or a hacker with limited skills who copies a database dump, is discovered from the unusual network load, and does not have time to fully investigate the system and extract the key from memory.

* If sensitive data is held on a separate service, but the web tier has read access to it - then the other service can impose rate limiting and unusual activity detection to block attempts to dump everything quickly.

* If the data is encrypted with the user's password, which is not stored in plaintext at all - then the attacker can at best only access accounts that log in before detection.

All of these still give an attacker full access, assuming they have infinite amount of time and skills. But for many practical scenarios, they can reduce the amount of compromised data.

[tomjen3]

Wouldn't that be a simple issue of limiting what the web layer can ask for? I mean sure it would allow the attacker to charge a creditcard - but hopefully only to an approved account, and he wouldn't ever see the actual details. Your web layer never needs them, so why should it have the right to ask for them?