Catching Credit Card Fraud through Steganography
by Anonymous Author MD5: d03d3293cd954af6bccd53eac5d828fc
In case you hadn't noticed, credit card fraud is all the rage these days.
This is not just for credit card criminals and organized crime; it goes all the way down to common clerks, waiters, and bartenders. In fact, perhaps the most common place to become a victim of credit card fraud is not when buying things off ThinkGeek or Amazon, but in places likes bars and restaurants.
In efforts to avoid being overcharged at these places I developed an interesting trick drawing from steganography (the art of encoding a message inside of a larger message).
Although I'll talk a lot about tipping in bars and whatnot, this article isn't about tipping. It is about covert encoding of extra information into monthly credit card statements, and will work for any credit card transaction.
But conveniently, this technique can be elegantly applied to tipping in bars and restaurants where perhaps it is also the most practically useful.
After you have finished your meal at a restaurant and give your credit card to the waiter, know that upon getting your card back with the receipt you actually haven't been charged yet. This is why you don't see a separate charge for the tip whenever you opt to also put that on your card.
What happens is the waiter first scans the card and verifies that the account is indeed valid, and then returns the card and receipt to you. When you have signed, the waiter goes back to the machine and charges your card for the meal along with any tip you might have left.
Though occasionally the cost for a meal itself is checked against the restaurant's computer, the only thing that prevents the amount of tip from being on the honor system is your copy of the signed receipt (of which most are just thrown away).
As you can tell, this is a situation just begging to be abused, and it often is.
A strategy to avoid this I (and many others) have come up with is simply to engineer your tips so that the final charge for the meal always comes in an unusual constant (say something like 17 cents).
Although this is a good start, it is fragile and the "secret number" quickly becomes very obvious to any staff when you regularly pay with your card.
Though weak, this very common idea of using a constant for the cents stops just short of a far better technique that works quite well.
The Technique
If you recall your last monthly credit card statement, it lists three fields for each charge:
- The date of charge.
- The company/vendor's name.
- The amount of the charge.
What we could do is make the cents in the charge a function of one of these values so we could quickly verify them on the monthly statement.
For example, instead of making the final charge end in some magic constant (i.e., 17 cents), we could dynamically generate the cents as a function of the vendor's name and then see if it matches up.
Though clever, using the vendor's name doesn't buy us anything that a constant wouldn't because you'll still always be ending up with the same cents value in the total every time you go to a bar you frequent.
Making the cents a function of the date is also an idea, since you're not very likely to go to a particular place on only a certain day of every month (and even if you do for some freak reason, you're not going often enough to be remembered by the staff).
This idea is pretty good and worth exploring, but not ideal.
Lastly, although it does not provide as much randomness as the date, using the amount of the charge itself when generating the number of cents has a very nice effect of doing much stronger checking for fraud; this is not obvious at first glance so more on this later.
In short, instead of using a constant for the cents value, by deliberately engineering your tips so that the cents value of the total charge is somehow related to the date or to the charge itself has great advantages for discreetly catching credit card fraud while taking almost no additional effort when calculating the total.
But enough with discussion.
To focus on the more complicated overcharge protection afforded by using the charge itself, in this example we'll ignore any additional usage of the date to increase the difficulty of your scheme being figured out.
Here's what to do next time you use a credit card at a bar or any place where you can put a tip on your credit card.
- Give the waiter your card.
- Wait for the receipt to come back (you haven't been charged yet).
- Say the cost for the meal is $12.34. What we want to do is engineer the tip so that the final charge has the dollars' value encoded into the cents. Here, we'll use the simple encoding of "For D dollars the cents should be D + 1." So, say we want to leave approximately a $2 tip. That means the final charge's dollar amount will be $14. So, since we're encoding cents of the final charge as (# of dollars) + 1, the final charge would be $14.15. So the tip will be: $14.15 - $12.34 = $1.81.
- Follow this same scheme anytime you have the option of tipping with your card.
- When you get the month's statement, quickly scan through the list of charges looking for any instances in which the cents does not equal: (# of dollars) + 1
- If you see a charge from a place where you can tip and the cents don't add up, you know the charge is fraudulent. Note that if only using the secret-constant or date method, you would only be alerted to tampering with the cents value. A check using (# of dollars) is much, much better as it protects against tampering with both the dollars and the cents values. (And really, aren't dollars more important anyway?)
Other (and Better) Variations
Just saying (cents = # of dollars + 1) is certainly not the only thing you can do, far from it.
In fact, it's probably a bad idea to use something as simplistic as that. Though realistically it's unlikely anyone but your mathematician drinking buddy (who unbeknownst to you also just happens to be working for the NSA) would pick up on something as obvious as the (# of dollars + 1), making it more complicated (and secure) really doesn't take any extra effort. Besides, your waiter might read 2600.
Anyway, you can just as easily use one of these more secure schemes:
Using bits of the date is easy because they're always printed on the receipt you sign. Although dates vary enough that no one will likely figure out a schema based on them, without using (# of dollars) somewhere you still only get alerted to cents tampering:
In the case of (# of dollars - N), you can decide for yourself what you want to do when N > # of dollars.
I personally like using the absolute value of negative numbers rather than cycling back to 100:
Using (cents % N) is nice because it lets you exercise finer granularity in tips.
Really, you can make the function mapping onto the cents as complicated as you want.
Everyone being able to use their own personal variation of this idea is very nice because even if, overnight, everyone started using such a system you'd still be protected because no one could casually determine what algorithm you personally use.
And, regardless of how complicated your algorithm is, going over your statement once a month is still sure as hell easier than keeping up with all those damn receipts.
Shortcomings
I'm fully aware people use credit cards for things where you don't tip. Deal.
In such situations, I've had some success in simply asking to be charged a few extra cents more for an item, but it's usually not worth confusing the teller in wondering why on earth someone would want to pay more for something.
Hotel clerks, although somewhat curious, don't seem to have too much trouble with this concept and will generally do as asked.
Walmart checkout drones are usually helpless when confronted with such strange notions. But, even with this shortcoming, bars and the like are common everyday expenditures and have some of the highest probabilities for fraud. So, any protection there is worth employing; some security is better than none.
Closing Remarks
For interest, I've been using this system for about a year and to my surprise I actually haven't caught any fraudulent charges with it yet.
I think perhaps the incessant strange tips and totals I leave make people more cautious than usual, or maybe I just hang out in more reputable places.
Lastly, as this is 2600, I couldn't possibly end this article without at least tangentially mentioning that if you're concerned about protecting whatever bits of privacy you have from corporations and government agencies (PATRIOT Act, etc.), you should avoid using credit cards at all - cash really is your friend.
Shoutz to yak.net and to Emmanuel for holding The 5th HOPE for us all.