I talked with a friend who actually had this implemented before and banks had signed off on it after reviewing it. load balancer (irrelevant to the security piece) web server(s) - only accepts traffic to port 80/443. can only forward requests on to the app server, one direction. app server(s) - processes the PHP/etc. has access to the encryption/decryption keys. can only send established packets back to the webserver, and traffic to the db. cannot connect outbound to the net. db server(s) - stores the data. choose how you want to encrypt. they did not encrypt data at rest in their setup, the bank would have 'preferred' it but was not willing to buy the license for the encryption plugin. however, the app tier could handle the encryption/decryption. all machines were only accessable via VPN, not the WAN. due to that, assuming physical access is not an issue: if the webserver got exploited, it could only talk to the app server using http. it has no access to the encryption key, nor the database. only one direction of communication. if the app server somehow got exploited (someone somehow got a trojan installed) it can't communicate outbound, so unless they figured some creative way to make the app server expose information through the open port only for the webserver, it's useless. and to install the trojan, typically people fetch remote files - well, the app tier can't communicate outbound. it's pretty damn secure for a web app. you could theoretically pair the app server and db server on the same box - you could probably make that work too. depends on how large you need to scale and the architecture required. anyway... anyone have any comments or holes to poke in this theory? On Wed, Jun 23, 2010 at 12:55 AM, Tommy Pham <tommyhp2@xxxxxxxxx> wrote: >> -----Original Message----- >> From: Peter Lind [mailto:peter.e.lind@xxxxxxxxx] >> Sent: Wednesday, June 23, 2010 12:22 AM >> To: Michael Shadle >> Cc: PHP-General >> Subject: Re: How to store encrypted data and how to store the key? >> >> On 23 June 2010 09:11, Michael Shadle <mike503@xxxxxxxxx> wrote: >> > This is somewhat related to the whole PCI/credit card discussion a >> > couple weeks back. The consensus was basically "leave it to other >> > people" - however, what if YOU are the other person? >> > >> > I wonder if anyone has some BKMs to share about encrypting data in a >> > web application. A lot of people take the most obvious approach, but >> > it's fundamentally flawed, that is: >> > >> > I take data from the user, I encrypt it (using PHP crypto, or MySQL >> > crypto, etc.) and a key stored in my config file, and put it into the >> > database. Then when I want to get it back, I just use decrypt + the >> > key in my config file. The issue there? If you server is compromised >> > and the database is accessable, they'll have the key to decrypt the >> > data right off the server. They can pull down copies of everything or >> > even write their own script ON the server itself to extract the data. >> > >> > This has been one thing that I have not really been able to figure out >> > yet. You could separate the servers, and figure out some very hard way >> > for them to communicate, but when it comes down to it, the webserver >> > needs to access the data. For example, the webserver could be behind a >> > fully firewalled setup that only allows MySQL traffic. However, the >> > webserver has to access the data still. >> > >> > I assume the only solution is somehow storing the key in a third >> > place, so the accessor has to get the key somehow before accessing the >> > encrypted data. But again - how to automatically allow access for only >> > the webapp? I thought of per-user keys, but that isn't an appropriate >> > solution for something that needs to be encrypted using the same key. >> > >> > Has anyone had to implement anything like this? Is there a good >> > whitepaper on something like this? Especially relating to HIPAA >> > requirements. PCI would be nice too, but I'm sure once this major >> > "unknown" in my mind is addressed, the general concepts are common, >> > probably just differences in levels of firewalling, cryptography >> > strength, physical access to the machines, etc. >> > >> > Please keep this on topic - this is about the people who DO have to >> > address this issue, not something about "just offload it to other >> > guys" - that's an obvious choice already, and not one that is allowed >> > depending on the job. >> > >> >> I haven't had to implement a scheme like this but for an app I'm working on >> we've been considering the same issues in order to keep member data safe. >> I would say your best bet is to keep the decryption key in memory while the > > This is something I'm very interested in hearing more about since our other discussion about PHP & threads and how some list members prefer the 'share nothing' approach. That said, how would you access the memory for every individual sessions that need that decrypting code/key when nothing is shared? (I'm assuming that this would be purely in PHP :) > > Regards, > Tommy > >> app is running. Initialize it by hand whenever the server is started - don't >> store it on the disk. Yes, your server won't be able to start up the app on it's >> own but that's the security in the design, not a flaw. If you want automatic >> access for the web-app you've compromised security (anyone compromising >> the server has automatic access as well). >> You're essentially looking at the old problem: if it runs it can be broken. You >> can only try to make it as hard as possible but there's nothing foolproof. >> >> Regards >> Peter >> >> -- >> <hype> >> WWW: http://plphp.dk / http://plind.dk >> LinkedIn: http://www.linkedin.com/in/plind >> BeWelcome/Couchsurfing: Fake51 >> Twitter: http://twitter.com/kafe15 >> </hype> >> > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
