On 23 June 2010 09:11, Michael Shadle <mike...@gmail.com> 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

Reply via email to