Re: How to store encrypted data and how to store the key?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux