in reply to Re: Encrypting strings with more than 8 bytes.
in thread Encrypting strings with more than 8 bytes.

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.

Replies are listed 'Best First'.
Re^3: Encrypting strings with more than 8 bytes.
by diotalevi (Canon) on Jan 13, 2006 at 14:27 UTC

    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.]

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      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.

        Lots of CPAN authors are too cautious with their warnings about "Oooh! Not for production!" I don't always believe them.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

          A reply falls below the community's threshold of quality. You may see it by logging in.