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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
