Re: Credit Card encryption

On Sun, May 30, 2010 at 03:12:10AM -0400, Adam Richardson wrote: > On Sun, May 30, 2010 at 2:16 AM, Ashley Sheridan > <ash@ashleysheridan.co.uk>wrote: > > > On Sun, 2010-05-30 at 01:49 -0400, Paul M Foster wrote: > > <snip> > > Hi Paul, > > When you describe one-way or two-way encryption, what are you describing? > Are you describing hashing vs encryption where the plain-text is > recoverable with a key, or are you describing symmetric (one key handles > encrypting and decrypting) vs asymmetric (separate keys handle encrypting > and decrypting) encryption? I'm not very good with this terminology. What I mean is that there's no way to decrypt the value without the key, and the key is not stored on the system. This would be like password storage on *nix systems-- if you forget the password, there's no practical way to log in. (Yes, I know there are dictionary-based and brute force methods, but in general, if you forget your password, you're screwed.) What PCI wants is strong encryption. I take this to mean that keys are long enough to be practically invulnerable to hacking. > > Now if you one-way encrypt the credit card numbers in the customer > > records, then it seems to me that any time that field has to be accessed > > (to edit the record or charge something to the card), you'd have to have > > the user enter a specific "password" to unlock the encryption. > > > You can't decrypt (or "unlock") a hashed password (at least if you used a > secure hash), but I'm not sure you're talking about symmetric vs asymmetric > encryption, either. With more details , I can provide feedback on the > encryption schemes you're considering (remember, you have to make sure that > you are managing encryption keys very carefully, as among other things, PCI > requires that "keys are stored in encrypted format and that key- encrypting > keys are stored separately from data- encrypting keys.") By "assymetric", I take it you mean like PGP or GPG, where there are public and private keys? I don't really understand this technology, and I'm not sure it matters. <snip> Paul -- Paul M. Foster