On Wed, Jun 23, 2010 at 6:09 AM, Peter Lind <peter.e.lind@xxxxxxxxx> wrote: > On 23 June 2010 10:09, Michael Shadle <mike503@xxxxxxxxx> wrote: >> On Wed, Jun 23, 2010 at 12:55 AM, Tommy Pham <tommyhp2@xxxxxxxxx> 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 > > Here are a couple of things which may help http://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet#Rule_-_Under_PCI_DSS_requirement_3.2C_you_must_protect_cardholder_data http://www.issociate.de/board/post/247319/Encryption_Key_Storage.html The biggest issue with it on web servers is simply time. If the key is too hard to get to, or unavailable due to a machine failure, then you are going to have pissed off customers/clients who won't be able to do much. The best solution is to store the CC data on a DB that is not web facing. That removes the need for the web app to hold the encryption key. You can store a hashed value, with the last 4 digits of the card and expiry on the web facing DB for any transaction processing verification. But those transactions should then move into a queue inside the secured network that is not web facing. This secured network can then take the data from the queue, find the appropriate record in the secured DB, unencrypt it and process it as normal transaction. Get back the verification of successful transaction and then queue that back into the web facing system for messaging the user. -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
