Just FYI, checking the "do not store card numbers, even at checkout" works great for us at the moment. Since it only stores the last four digits of a card, I'm still able to process the payment as well as issue refunds to users when they need it. But I can't remember if that's the default, or if the default is to store the entire number. (It's been a while since I installed UC).

In any case I think if someone is storing the entire number there should be encryption in place; you may even consider encrypting anything that gets stored in the cc_number column.

If someone gets complete access to your database, you're pretty much hosed. Any encryption method that allows decryption can eventually be cracked by someone with enough time and determination. That's probably a lot easier than getting into the database through all that security, anyway.

The best practice is to really not store the entire number at all.

CC Encryption is definitely an issue that needs to be addressed. While Lyle is technically right that any two-way encryption scheme can be decrypted if someone has the resources, it is HIGHLY unlikely if the encryption is done correctly.

Lyle is also correct that the best policy is not to store the CC numbers at all, but that is not always an option. For systems that require recurring billing, keeping the CCs in integral. So a solution needs to be found. Additionally, Ubercart (currently) stores the CC in the database between transaction stages. So if someone abandons their cart (even if they have the option checked to not store CC numbers after the transaction), the CC remains in the DB. That CC should be encrypted, even if it is only temp storage, because you never know when a user will abandon the cart, or close the browser for another reason, and if the CC will be in the DB it will be stuck and potentially exposed.

Even if MD5 were a two-way encryption methodology, it is not strong enough for CC numbers. Too may Rainbow table projects exist for it. Something stronger is needed.

Mcrypt is likely the best solution. It is relatively easy to implement and it seems solid.

Using MCypyt with AES/Rijndael (128, 192, or 256) should be MORE THAN adequate protection for storing CC numbers in an Ubercart DB table. By using MCrypt with AES/Rijndael on a credit card number with a Random Salt concantenated and then a site salt and an administratively set cipher key, those numbers would be encrypted and obfuscated beyond reasonable means for decryption.

So what I am envisioning is a DB entry into cc_num(blob) built like this

$random_salt = md5(uniqid(rand(), true));
$text = $site_salt . $cc_num . $random_salt;
$crypttext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $text, MCRYPT_MODE_ECB, $iv);

Compnents of $text:
1. $site_salt - Would be a salt that the administrator would create and store in an offline file (perhaps settings.php)

2. $cc_num is the plain test CC number

3. $random_salt is a random unique id generated on the fly for each user and stored in the DB, perhaps in a salt table that is related either to the user table, where each user would have their own salt, or to the uc_payment_credit table where each CC payment would have its own salt.

This way the "bad guys" would need more than just access to the uc_payment_credit table to be able to do anything with the encrypted credit card numbers. They could begin trying to brute force attack those numbers, but in 100+ years, when they finally succeeded, would anyone care?

To crack the encryption, they would need access to the database, AND the key stored in the protected system file (Which should be possibly be excluded from off-site backups).

The random_salt is merely there to protect against brute force attacks against the credit card table. If the entire db is compromised, the random salt only helps with obfuscation.

Now, I am not an absolute expert on this stuff. I am also not a PHP developer or Drupal Develper by training, however I am working on it. I am a ColdFusion developer and I have been researching CC and Password encryption for some projects. I am a Drupal user and I am currently setting up an Ubercart site for a friend, and when I saw that cc_num was being stored in plain text, I had to say something. If there are glaring errors in my logic, I would like to have them pointed out to me.

AES/Rijndael 192 and 256 encryption are an acceptable standard for US Government Secret and Top-Secret classified information protection link, so they are probably good enough for an online store.

Another solution I ran across: cron job to remove sensitive customer info from the exposed server and download to a secure, essentially offline server.

Obvious disadvantage: you have to do all of your order processing from the back end.

However, if your online store is only one facet of your operation, you might have to populate an offline order system anyhow.

Best regards,
Alan