Though Crypt::CreditCard looks like a good approach, the only versions availabe on CPAN are developer releases and the perldoc explicitly states it is not intended for production use at this point.
Unless you want to display the credit card number back to the user at some point (which does not sound like good practice to me) you may want to look into using an asymmetric encryption method (such as GPG) for credit card numbers. This ensures that the numbers cannot be stolen even if both your database and the public key you use to encrypt the data have been compromised (providing you keep the private key off-site and safe).
There are ten types of people: those that understand binary and those that don't.
| [reply] [Watch: Dir/Any] [d/l] |
I ddidn't read the pod closely enough to see the warnings but did notice that it was accepting some kind of keys and I vaguely guessed it was doing something asymetric. Maybe not. It's what Andre should be using: it leaves things safe on the public computer. [Added; My language wasn't clear. "It" in "It's what Andre should be using" referred to something assymetric like gpg. I was agreeing with whoever it was that I was responding to.]
| [reply] [Watch: Dir/Any] |
No, Crypt::CreditCard uses AES, which is a symmetric cipher. But it cleverly uses the user password as part of the encryption process (and ideally that password should not be available to the system unless the user is logged on), so it's a good method to use when you need access to the credit card number from the website with user interaction.
Still, given that it's marked as non-production I would say Andre should not use it unless he's not intending his system to go into production.
There are ten types of people: those that understand binary and those that don't.
| [reply] [Watch: Dir/Any] [d/l] |
Since you're encrypting credit cards
Sometimes I miss things, but where did the OP say anything about credit cards?
thor
The only easy day was yesterday
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |