The level of liability that a store owner opens themselves up to by storing credit card numbers is huge. Of course storing CC numbers and passwords anywhere that are not encrypted is a huge security hole.

To be frank, I strongly recommend against this practice, especially if you are using open source code. You can easily issue credits through payment gateway providers such as Authorize.net, Versign, and TransAction Central....

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.

I use the "Don't Save CC Numbers, Even at Checkout" setting as well, but it still doesn't solve the issue of clearing out full CC numbers if an order is not successfully completed.

Other than having the Cron chop up left-behind credit cards every night, is there a way to prevent them from being stored?

Hi Chris,

We are also using the "Don't Save CC Numbers" option, and your statement about the problem of clearing out CC numbers if an order fails grabbed our attention. Under what circumstances might this occur? We are wondering if we would have to write some kind of custom script to comb the database and clear out any such lingering CC numbers, but we're not sure what sequence of events would lead to such an unintended CC number storage.

Thanks,
Chuck & Kim

I ended up grabbing Tony Marston's encryption class for use in core (it's GPL and has no external dependencies). As I was reviewing the credit card settings to figure out where to put the encryption settings, I realized that the last few fields can be used to take care of the sort of "leftover" cc numbers described in the above 2 posts. Just set the order status to wipe to "In checkout" and put the time limit to 1 hour. Is there a problem with this?

Also, as we move forward, I'm considering the fact that including configurable messages in settings forms has led to problems with multilingual sites. Does anyone alter the failed CC message or can I just make that a default and remove that textarea? It would still be editable through translations/localization.

Alright... moved all the CC settings around, made them more logical with better help text, and I documented all the settings in the user guide. Please review that compared with the attached screenshot and let me know if it makes sense. Once encryption is complete I'll make a separate post about it instructing users on how to best protect themselves and their customers from fraud.

I know tP saw the other post, but in case anyone else didn't who's tracking this thread... CC encryption has been committed to core with a few functions for existing sites to encrypt any existing data as well. This change also totally restructured the CC settings form to make it a little more logical.

http://www.ubercart.org/forum/announcements/2762/cc_encryption_bazaar_ne...