On 23 June 2010 10:09, Michael Shadle <mike...@gmail.com> wrote: > On Wed, Jun 23, 2010 at 12:55 AM, Tommy Pham <tommy...@gmail.com> wrote: > >>> 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 :) > > +1. each server stores it locally in APC, or you have to mess with > memcached, and since it is plaintext, encrypt that too? :p > > I -always- design for 'shared nothing' so this is a necessary > discussion too, if "in memory" is the idea. >
In memory means that any of the php processes spawned by the server would have access to it. Encrypting it in memory really doesn't help you, as the php process would then decrypt it, bringing you back to square one: you just mimic the decrypting behaviour of a working php process to get the plaintext key. Shared nothing also doesn't help you - that just multiplies the amount of places the key is placed because you're still facing the same issue: the scripts need access to the key. You could possibly devise an authentication scheme by which a script could authenticate itself to a server that would then hand out the key ... but that's susceptible to other attacks as well. So I'd probably stick the key in memory, possibly memcached. I'd encrypt it but nothing special, just making sure that you cannot get the plaintext from memcached without digging through working php files to figure out how you decrypt it. Then I'd monitor the solution to see if anything *weird* was going on, wiping memcache if something strange comes up. As should be obvious, this doesn't solve the problems. Your number one priority is blocking access to the server. Number two is making sure that noone can use the data *if* they get access but without working scripts. If someone roots the server with everything up and running, there's really very little you can do. This is getting offtopic, though, if memory serves. I believe PCI has some strict requirements on how security should be implemented. You'll have to follow those and not other schemes that may be more or less secure. 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
