If you search the Hazel knowledge base, you will see there have been intermittent queries as to how best to encrypt the emails that Hazel uses to send credit card numbers. The consensus has been that the risk of sending the emails is very low, provided the email messages are stored on the same server where Hazel resides prior to being sent. The further consensus is that implementing an encryption program such as PGPSendmail or GnuPG is a hassle, there are limits to how a commercial operation can support PGP (though I take it GnuPG is a different story) and it's just not worth the trouble. There's also the issue of having to send half the email messages (the store invoices) encrypted while sending the other half (the messages to the customers) in clear.

For all of that, there is something unsettling about email messages with unprotected credit card numbers flitting hither and yon -- and maybe accumulating on the receiving computer. Just today, it struck me that the only thing that needs encryption is the credit card number itself. Furthermore, having that number off by a mere one digit ought to be enough to render it useless. If the card number were scrambled just a trifle, and still looked like a legit number, and it were done in such a way that the original number would be easy to recover, that would be encryption enough.

I got the idea of using the credit card number itself, and/or other numbers sent in the store invoice, as a source of very basic encryption keys. The example below take the first two digits of the credit card number and the last two digits of the client number and multiples them together. It then adds that result to the last six digits of the credit card number, and then prepends the first part of the credit card number to the addition result. It is in four sections, to accommodate card numbers of 13, 14, 15 or 16 digits.

The idea is to do these calculations on the store invoice after Hazel has done her initial checks on the credit card number and established that it is potentially valid. Since error-checking has already been done, it doesn't have to be done here. We can't get to this point in the process unless we have a properly formed card number.

Once this very light encryption has been done, all that has to be done at the receiving end is to multiply the two values by each other and then subtract them from the reported card number to get the original card number. It would be duck soup to set up a little program, or a spreadsheet worksheet, into which the scrambled card number and the encryption keys could be cut-and-pasted, and which then would recover the original card number.

I am deliberately leaving one flaw in place here to make a point about selecting your keys carefully. By using the last two digits of the client number, I am leaving myself open to the one-in-a-hundred chance that the last digits will be 00, which, when multiplied by something else, will give the result of zero. When added to the credit card number, you'd get the number in clear. (Enter a bogus card number that starts with two zeros (impossible in real life) and you'll see the card number comes through unscrambled.) For this reason, it is probably wiser to use the leading rather than trailing digits of a number (because the first two digits won't be zero) and/or to add a fixed value to the final scrambler number before adding it to the card number. If you added three to whatever else the calculation came up with, you'd still have knocked the card number off by something, even if your previous additions and multiplications came up zero.

A few other notes on the process:

• The card number is split up and then stuck back together because Hazel's Math tag flips like a cheese omlette when called upon to do calculations using a sixteen-digit number.
• There are any number of numbers than could be used as the keys for the scrambler -- the customer's phone or zip code, the timestamp of the invoice, the card expiration date, etc.
• Care should be taken to select a scrambling method that doesn't add or remove digits from the final result. (That's why I pull up six digits of the card number and add a four-digit number to it. Adding the highest possible 4-digit number -- 9999 - can't change the length of a six-digit number.) If I called up a four-digit value and added another four digit value -- or subtracted a four-digit number -- I'd stand a good chance of changing the length of the reported card number, making it look less like a real number, and making it that much more likely to cause decryption problems.)
• Also note that only the last five digits of the card can change using the technique shown. If something goes badly wrong, all you have to get from the customer is the last five digits of the number -- you'll have the rest of the original number. The customer will be more confident and trusting if he or she only has to give a partial number.

What is shown here is a demo. In real life, you'd replace HZV_CREDTEST with HZE_CREDIT_CODE, and insert the calculation loops into your store_invoice.txt template. Obviously, you would not display any of the interim values, but would merely show the results, formatted to make the card number look real. You'd remove the HZM_PAYMENT_INFO tag, which shows credit card info in this manner: "XXXXXXXXXXXXXXXX (type, expires XX/XXXX) issued to'cardholder name'" and instead provide the information in the fields HZV_SCRAMBLED_CRED, HZE_CREDIT_MONTH, HZE_CREDIT_YEAR, HZE_CREDIT_TYPE, and HZE_CREDIT_NAME. (Note: I have deliberately omitted the leading % (percent sign) from the Hazel Tags in this paragraph so Hazel wouldn't actually try and present the values instead of the tag names.)

Created on ... February 04, 2005