Wow. Simply wow. What excellent suggestions!
On 15-Aug-06, at 12:26 AM, Matt P. wrote:
Use asymmetric encryption. The decryption key is stored somewhere
totally
non-web-accessable and the encrypted data gets transferred off the
web at
user’s behest and then decrypted on the local machine.
Great one! If I understand you correctly, the card gets encrypted
with a public key, the client then calls the number up on the screen
in its encrypted form, punches it into their local decrypter with
their private key (the password to which is presumably stored in
their brain) and voila â?? plain text!
On 15-Aug-06, at 12:26 AM, Devin Ben-Hur wrote:
Upon receipt of a credit card from a web form, your app passes the
payment server the card info and gets an encrypted result for
storage. When you are ready to make a transaction, your main app
requests the payment server to conduct a transaction (passing the
encrypted info). The payment server is the only thing with
knowledge of the encryption key and the capability of turning
encrypted card info into plain text. In normal mode it only does
this for the purpose of sending a transaction to your gateway; in a
special admin audit mode it can be used to decrypt data for plain
text display, but you want this to require significant authentication.
Another great idea! I somehow start a (BackgrounDRb?) interface
between my Rails app and this Hardened Payment Server, using
authentication that’s stored in my brain. That way, when the
connection dies, access to the admin audit mode dies with it. A
hacker would have to get into the webserver, and find a way to steal
my password out of the interface’s memory, while it’s running,
without bringing it down. Complicated, but interesting!
One issue you’re going to run into is a conflict between records
retention (for answering chargebacks, issuing refunds, issuing
recurring charges, or return customer convenience) vs data security.
Good point! In this instance though, records retention won’t be a
problem. My client needs the number stored in the webserver only long
enough for them to pull it up and type it into their POS machine.
After that, their record will be on the paper slip, and can be safely
deleted from the webserver.
On 15-Aug-06, at 12:35 AM, Tom M. wrote:
I think the better approach is to use public key encryption on the
web machines, passing the encrypted data to the secure payment
server, which decrypts via private key. The private key should be
encrypted itself and passphrase manually entered each time the
payment server is started, so that a hacker will not find it
laying around in a file somewhere, nor will they find a useful
private key.
I think, between these approaches, we’re on to something!
Quality people on this list. Quality. Best first post I’ve ever made.
Steven L. (BDes Hons., Provisional RGD)
{
c = Steven L. Design;
w = http://www.stevenluscherdesign.com/
}
PS. Is it worth mentioning, for the purposes of all this PCI talk,
that I live in Canada? Do we have different rules here?
PPS. Yes, I realize that it’s so ‘pen and paper’ to insert
postscripts at the end of an email.
Attention