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 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
