Ubercart

Thus, the exception. Yeah, in the encryption, I had to decide what to make different lengths. Personally, I don't think you can get much from knowing what type of card someone has. I know anyone else in Louisville w/ a 5/3 Bank account will have a Mastercard debit/check card, but I can't really do anything with that I don't have a way to restrict what someone puts in that textfield, so I didn't bother mashing it up to some custom string... so yeah, encryption on the card type field is fairly worthless as is.

Sorry about jumping into this thread so late. When it was first posted, the above link to the "GPL encryption class" was broken, so I couldn't evaluate the algorithm. Then I forgot about it until I saw a related post this morning (http://www.ubercart.org/forum/development/3591/ubercart_and_credit_card_...). I've now read up on it and I'm not real comfortable with what I see.

Bottom line: The current encryption method is extremely weak and should be replaced as soon as possible with strong public-key method.

(Ryan, I realize that this post sounds a little critical, but the criticism isn't aimed at you. Protection of credit card numbers is an important issue, and you've taken the time to address it in Ubercart, which is great. And as far as I can tell Ubercart handles the issue at least as well as any other open source e-Commerce solution. So please read the following as a condemnation of the algorthm, and not of you.)

Ubercart uses http://www.tonymarston.co.uk/php-mysql/encryption.html as the basis for its credit card encryption. That URL describes a keyed polyalphabetic substitution cipher, similar to the Vigenère cipher which was first created in the 16th century and was used frequently by the South during the American Civil War. (Interesting historical note: Charles Babbage was the first person to figure out how to break this cipher, sometime in the mid 1800's). These types of ciphers can be quickly cracked with a computer since a frequency analysis will determine the key length and a dictionary search or even simple combinatorics will yield the key. (Lengthening the key past 16 characters - the length of a credit card number - will not help). Likewise, if you have even one piece of plaintext to compare to the ciphertext (e.g. you place an order with a known credit card number), the key can be recovered almost trivially. Compounding this is the regularity of credit card numbers: The first digit is known, there are only 10 symbols (0-9) used in the number, and the checksum built into the number restricts the possible combinations. Also, the more encrypted credit cards numbers you have the easier it becomes to recover the key.

Frankly, given the availability of extremely strong open source encryption algorithms, there is IMO no good reason to use the current method. I think I understand why it was chosen - the Drupal GPL requirement and the availability of a PHP implementation - but these are poor criteria. The only thing that matters is, can the encryption method adequately protect the credit card numbers? For the current scheme, I have to say no.

That said, now that the encryption framework is in place, it's probably easy to plug in a new algorithm. I wish I had time to tackle this myself, but TCS, in his post referenced above, seems to have a solution almost ready to go - I think this should be examined and folded into core right away!

Hey Bob, I'm glad you're digging right into the security of Ubercart even as a newcomer. More eyes are a good thing.

In response to your question, the main reason is I didn't know those existed. I suppose now that I do, a second reason would be questions of compatibility. For example, can these functions be used in a shared hosting environment, do they work uniformly on all recent versions of MySQL, and is there a Postgres equivalent? We don't officially support Postgres, but we've been including contributed support from community users who use Postgres themselves.

I'd appreciate any insights you have.