I understand the concepts of securely storing data for the most part, including storing the data on a separate server that only allows connections from the application, key-pairs for encryption, etc. However, I’m still not understanding how separating the server makes it that much more secure.
For instance, suppose I have a web server, which is hardened and secure, and it captures the data from user input for storage. The data is encrypted and submitted via a db query or web service to the db server. The db server only allows connections from the web server and stores the data in an encrypted form. Therefore, if someone access the db, the data is worthless.
But, if someone access the web server, they will have access to the db as well as the encryption algorithm and keys, no? That being the case, why even have the data on a different server, as the transfer of the data is just another potential point of attack?
Is there someway to hide the connection information and encryption algorithms on the web server so that if it is compromised, access to the db server is not gained? Obfuscation isn’t enough, I wouldn’t think. Any ideas are welcome.
Thanks
Brian
There’s a certain amount of magical thinking and folklore in the way people design for security, and you’re right: storing data on a different server on its own doesn’t necessarily make things more secure unless you’ve done all sorts of other things too.
Managing keys is a huge part of this; doing this in the context of web applications is a subject apart, and I’m not aware of any robust solutions for PHP. You’re quite right – if your web application needs to be able to decrypt something, it needs access to the keys, and if the web app is compromized, the attacker also has access to the key.
This is why I’ve tended to use public key cryptography, and treated the public facing webserver as “write only” – i.e. the web server encrypts using the public key, stores in the database, and can never decrypt it; only a separate process (not available on the public internet) can use the private key to decrypt it. This way, you can store credit card details in your database, and only the application which charges the card has the private key to decrypt it; this app runs on a secure environment, not accessible from the internet.
Secondly, there are multiple levels of compromise – for instance, an attacker might get read-only access to your server’s file system. If that file system includes the database, they could get hold of the data file, restore it to a server they control, and use the decryption key to steal your private data. If the database runs on a separate server(inaccessible from the internet), this attack route becomes impossible.
The fact that one route of attack leaves you open doesn’t mean you can’t protect against other attacks.