Skip to content
Naked Security Naked Security

324,000 payment cards breached, CVVs included

When you decide to add debugging logs to your payment application, the PCI DSS rules about what you are allowed to store DO NOT CHANGE!

About two months ago, a Twitterer going by 0x2Taylor announced a sizeable data dump.

More than 300,000 credit card records were uploaded to the file sharing service Mega; the data has since been removed from Mega, but not before it was widely downloaded by many interested parties.

By some standards, 300,000 stolen records doesn’t sound very many these days.

That’s a sad state of affairs, of course, caused by the daunting size of some high-profile attacks that have hit the news recently.

This year alone, we’ve reported on breaches covering about three orders of magnitude, where each breach is in the exponential vicinity of ten times bigger than the one before it in the list:

Nevertheless, this newly-announced breach, dumped in a file by the name Bluesnap_324K_Payments.txt, is intriguing because even though the breach doesn’t include full credit card numbers (the so-called “long number” on the front of your card, usually 16 digits), it does include CVVs.

Understanding the CVV

CVV is short for Card Verification Value, confusingly also known as a CVC, where the second C means Code, and as a CVV2, where the 2 means it’s a “version two” CVV code, not that it’s the second such number on your card.

On most cards, the CVV is a three-digit number printed, rather than embossed, on the back of the card.

The CVV is often printed on top of the fragile signature strip, and is never encoded into the data stored on the magnetic stripe.

The idea is that the CVV is a basic anti-fraud mechanism for so-called Card Not Present transactions, which is why you are often asked for it when paying over the phone or online.

A skim of your card’s magstripe, or an imprint from an old-fashioned zip-zap machine (they still exist!), doesn’t capture the CVV.

If crooks get hold of a traditional credit card dump, consisting only of data that can automatically be acquired from the card, they can’t easily use your card online.

The crooks can, however, create cloned cards, using counterfeit blanks bought online, at least in countries that still widely accept unchipped cards, and go on a spending spree.

In this case, they often recruit money mules who are already in trouble with the law, for example because they’re illegal visa overstayers who can’t get jobs and are desperate for undocumented income.

If the dishonest purchasers are caught, they’re in double trouble, and they can simply be hung out to dry by the crooks, left to face prosecution, prison and deportation in no particular order. (Basic vigilance during the sales process and at the checkout can often rumble this sort of fraud.)

But with a skimmed card and the CVV, the crooks can use stolen cards online, without ever entering a real shop, standing in front of a checkout person, being asked to show photo ID, or facing up to a suspicious security guard.

Securing the CVV

Of course, the ongoing usefulness of your CVV depends very heavily on it never, ever being stored permanently anywhere except the printed digits on your card.

Once a transaction goes through, the CVV should be discarded and not left behind in memory, saved on disk, written into a logfile, or otherwise helpfully remembered until next time.

In fact, in this so-called “Bluesnap” breach, it looks as though the payment processor didn’t intend to save the CVVs, but nevertheless managed to dump them into the stolen database as part of a debug log.

According to well-known breach-tracker Troy Hunt, the dumped database has fields such as first_name, last_name, expire_year and other bad-enough-on-their-own data items.

But it also has a giant field at the end of every record called xml_debug, in which all sorts of additional data, including the CVV, is included as a blob of XML.

The XML includes a subfield called card-number that is rendered as TAKEN OFF FOR SECURITY REASONS, even though it’s technically lawful to store card numbers (though they must be protected when saved).

Ironically, however, the redacted card number is almost immediately followed by another subfield called security-code, where the never-to-be-stored-at-all CVV code can be found in clear text.

Bluesnap, which gives its name to the file that was dumped, is indeed a payment processing provider, but the company is quoted on Troy Hunt’s site as saying:

We were not breached. Immediately following the original discovery, we hired a top Security Consulting firm to run an audit of our environment. They concluded that BlueSnap was not the source of the data loss.

Troy Hunt suggested that a payment processor called Regpack, a customer of BlueSnap, might be the source of the leaked data, and was originally told:

As a preventive measure, we ran a full forensic investigation and it has concluded that there was no data breach on Regpack servers. In spite of that, we have run the full security protocol implemented in these cases and conclusively determined that our servers were not involved.

But that denial was later replaced with this updated statement:

Regpack has confirmed that all payments information passed to the payment processor is encrypted on its databases. Nonetheless, periodically, this information is decrypted and kept internally for analysis purposes. We identified that a human error caused those decrypted files to be exposed to a public facing server and this was the source of the data loss.

Curiously, Regpack went on to say that “[n]either Regpack nor BlueSnap had our systems breached,” which seems a peculiar assertion under the circumtances.

Regapck also neglected to mention that the data it “kept internally for analysis purposes” included CVVs, which may not be kept for any purpose, whether encrypted or not.

What to do?

  • If you request and use CVVs at any time, you MUST NOT store them, so don’t. Don’t write them down on paper, don’t save them to disk, don’t include them in logs, and never keep them “for analysis purposes.”
  • If you keep debugging logs, review them regularly to make sure you aren’t storing prohibited data by mistake. Don’t allow programmers to add data collection features to production code without a strict approval process, even if their motivation is to do the right thing and fix a known problem.
  • If you record phone calls “for security purposes,” don’t record the parts during which you expect purchasers to read out credit card details aloud. The irony of weakening security under the guise of improving it, by carefully recording prohibited data, should be obvious.


Individuals can also protect themselves by scratching out the CVV code on the back of their card (after recording it, perhaps in a password database). Why? When a wait-staff takes your card to run your restaurant bill, that’s the perfect opportunity for the person to snap a cellphone photo of the front/back of your card — with your CVV. Before you get home, they can order up lots from online retailers, and you’re stuck cleaning up the mess.

Just don’t forget your CVV, else you’ll be ordering a new card from the bank.


I like to do this, but please do be careful. Firstly, make sure you have memorised it before you expunge it. (I think you should *not* store it in a password database, simply because no one is supposed to store the CVV, even if encrypted, and “no one” includes you :-) Secondly, scratching off that flaky white coating from the “signature stripe” reveals the words VOIDVOIDVOIDVOID underneath, which is enough to cause some sensible merchants to refuse the card. So rub off the CVV code alone, and really gently, so it doesn’t leave you with a useless card.

Oh, never give someone your card to wander off with. (In Chip and PIN countries that should never happen – they should bring the payment device to you. That also lets *you* insert the card, so you can be sure it gets chipped and not swiped.)


I wish the States would get with it and use Chip and PIN! At the moment, there is no practical way to pay at most “sit-down” establishments without relinquishing control of your card (the payment device is usually a non-portable POS machine, and it’s often kept in areas of the restaurant where customers are disallowed (or at least discouraged). Even when paying with a debit card, which usually requires a PIN, the signature is substituted. I don’t like it, but hey, what do I know? I’m just the customer.


I take your point about VOID appearing; on 2 of my cards (that I carry daily), the CVV appears in a box outside of the signature block, so it doesn’t reveal that tamper indicator. I haven’t been outside the US in over 20 years, but its not uncommon to hand a credit card to waitstaff when settling a bill; I wish they would carry a device to the table. As you well know, the US is far behind adopting C&P; mores the pity.


Of course, I haven’t yet quite convinced myself that a card that said VOIDVOIDVOID would be rejected at all, given the scrutiny most non-Chip cards seem to get :-)


I believe there are two CVV style numbers. One on the mag stripe for in person card reads (point of sale) and a different one on the back for on-line transactions.


BlueSnap is a payment gateway and would have the card number and the CVV during the processing of cards. Would it be too presumptions of me to assume that the breach was from Bluesnap?


The breach was on the Regpack side, as evidenced by the extent of the data logged. The payment processor only receives (and needs) the XML API call that’s included in the data. The fact there’s more than that tells us that this was from the pre-processor on the Regpack side.

Regpack and Bluesnap have actually updated Troy with a statement reflecting my assumptions. It’s posted on his blog. (Update #3 at bottom of page)


Yep, Troy emailed me to get that aspect of the article corrected. I am sorting it right now…watch this space. Regpack, it seems, were at fault, though still seem to consider this “not a breach.” I would be interested to know what word or words might best be used instead :-)


A CVV exposure and consequent proof of illicit CVV storage should be sufficient reason for Visa / Mastercard (etc) to revoke the merchant’s ability to access their payment systems.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!