Re: Encryption For Specific Column- Where to store the key - Mailing list pgsql-general

From Craig Ringer
Subject Re: Encryption For Specific Column- Where to store the key
Date
Msg-id 4DF97FCE.1080706@postnewspapers.com.au
Whole thread Raw
In response to Encryption For Specific Column- Where to store the key  (Manuel Gysin <manuel.gysin@quantum-bytes.com>)
List pgsql-general
On 15/06/11 14:07, Manuel Gysin wrote:

> A discussion about this topic can be found under http://www.experts-exchange.com/Database/PostgreSQL/Q_21934798.html

Use Stack Overflow instead ;-)

Anyway: Given the additional detail you provided in that post, where it
becomes clear that you only need to be able to *read* the CCNs
occasionally and only in batches, perhaps you should consider using
public key crypto.

Store the last 4 digits of the CCN unencrypted but not the CVV or expiry
time. That way you can show a hint to the user about which card you're
using without them (or anyone else) being able to extract the full details.

Encrypt the full details using a public key when you store them in the
database. The web front end only needs to know the public key to encrypt
data. It doesn't need to know the private key, and without it it cannot
*decrypt* the data again.

Now your batch invoicing program can load the private key off a USB key
or SD card - or just keep it on disk and decrypt it using a strong
passphrase that is hand-entered by a user. When you're not doing
invoicing and billing, your system doesn't have any access to the
private key and cannot decrypt the stored data.

If you switch to rolling billing later on, you'll need to adjust this
process, but it still allows you to keep the part that can read the
credit card numbers very separate from the part that interacts with
untrusted users over the Internet.

--
Craig Ringer

pgsql-general by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Encryption For Specific Column- Where to store the key
Next
From: Craig Ringer
Date:
Subject: Re: You could be a PostgreSQL Patch Reviewer!