NYCPHP Meetup

[csnyder]

On 8/4/06, Mitch Pirtle <mitch.pirtle at gmail.com> wrote:
> I'd like to back this question up to the very beginning, and ask a
> more fundamental question that's been nagging at me for several
> days...
>
> So a client comes up to you with an intent to require encrypted data
> in the database. This of course requires two-way encryption, which
> unfortunately means you gotta store the keys on the webserver to
> decrypt the data.
>
> So what additional security does this actually accomplish, and is
> there a better approach?
>
> -- Mitch


By making the decryption key available to the webserver, the benefit
of encrypting the data in the first place is extremely questionable.

The only way to safely handle this is to keep the decryption key in a
separate place. You could either provide it to the original server on
demand (via a form field) when someone needs to work with the
encrypted data, or (better yet) you could bring the encrypted data to
another, locked-down system and perform on-demand decryption there.

Typically, you're storing credit card details, right? The only
person/system that needs to decrypt these is the person/system that is
performing the actual act of charging the card. Nobody else in the
order chain needs the data, so it should be trivial to set up this
kind of separation.

-- 
Chris Snyder
http://chxo.com/