Tesco's reaction—overreaction? Ludicrously counterproductive overreaction?—was fueled by the interaction of mobile and self-checkout. That mobile/self-checkout part is where barcodes can be fed into systems manually. But if you think this is no more dangerous than a shopper getting a $3 half-gallon of milk for 3 cents, think again. It goes way beyond fake product barcodes to include fraudulent coupons, forged giftcards and SQL injection attacks.
The programmer who started this, Matt Evans, filed his initial barcode musings late last month. Tesco's lawyers got wind of the discussions and slammed Evans hard with various legal threats. The page with the discussion was quickly taken down and replaced with a note saying, "Understandably, Tesco weren't best pleased. Here ends playing with their barcodes." Fortunately, a copy of the original page had been preserved prior to Tesco's threats, so we can see what all the fuss is about.
(Note: The one part of the code that Evans had been unable to figure out was the so called red number, and a commenter offered this: "In case anyone is interested, I've spoken to a friend of mine who was once a manager at Tesco and I can shed a little more light on the matter. The red number, which the author had so far been unable to decipher, is the 'discount-reason-code,' which represents the reason for the discount. These reasons represent things like 'damaged' or 'short date (nearly out of date).'")
Some comments suggest that Tesco likely has a price database, making fake prices useless. If so, why the slap-down? Surely Tesco knows these discussions go on routinely. If the company has legitimate security, what harm can come from people trying to analyze its very public barcodes? Surely Tesco understands that security by obscurity (where something is secure as long as no one stumbles upon it) never works, and it certainly can't work in today's Web collaborative environment.
One longtime security executive at a very large national retail chain said the issue in this case that troubled her is the ability of a user to either create his own barcodes and display them on a mobile phone or simply key them in. Self-checkout enables the machine access that makes this type of attack possible.
"There is the lesson that a bad guy can and will scan whatever barcodes he wants into your self-checkout machines and no cashiers will spot it," she said, adding the examples of the coupons, giftcards and SQL attacks. "There is also the lesson that whatever values you store in a barcode can potentially be deciphered by an attacker and may even be modified and used against you."
Aside from having better security, does it make sense to impose restrictions on self-checkout system interactions? Perhaps a ban on mobile/self-checkout interactions, forcing the customer seek an intervention for such a move? (Simply tell associates monitoring the systems to immediately halt mobile efforts.)
The same thing applies for manual barcode entry. If the product isn't scanning properly, seek associate help. Only with an override key and password can a barcode be manually entered. A product barcode not scanning should be indicative of an irregularity anyway, so an intervention is appropriate for both customer service and loss prevention reasons.
The legal threat Tesco likely used in this case—Tesco was given an opportunity to comment for this story and opted not to—was fraud, if the programmer had performed this on a machine and kept the money. But that threat would only make sense if a real security hole exists. If a pricing database would have blocked it, why the fuss? Put in a Shakespearean context: "The lawyer doth protest too much, methinks." Or in an American version: "If there's no threat, then why are you sweating?"