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