I just read this article in CNN Money and am trying to figure out what the vulnerability is:


Computer security researchers at the payment technology company NCR demonstrated how credit card thieves can rewrite the magnetic stripe code to make it appear like a chipless card again. This allows them to keep counterfeiting -- just like they did before the nationwide switch to chip cards.

This suggests that if the stripe is not present or invalid, then the attack is not possible. But then it goes on to say...

This claim of a glaring hole in EMV, the chip-based system, is possible because of the way many retailers are upgrading their payment machines: They're not encrypting the transaction.

This sounds like an entirely different vulnerability. Does anyone know more about this vulnerability, and if it can affect a card that has had its stripe blanked?

  • I cannot seem to find a video of the talk yet, only more vague articles. A video of the full talk might be uploaded to the Black Hat YouTube channel within the next week or so.
    – Spencer D
    Aug 4, 2016 at 19:52
  • I think this is the PDF of their slides.
    – Bobson
    Aug 5, 2016 at 3:31

1 Answer 1


I haven't seen the talk, but based on the description and their slides, I'm pretty sure that you're conflating two separate attacks.

... credit card thieves can rewrite the magnetic stripe code to make it appear like a chipless card again.

The magnetic track data on a credit card contains (among other information) a three-digit service code. A service code that begins with a 2 or a 6 indicates that this is a chip card, which is how the terminal knows to tell you to insert the chip if you have one. By changing that first digit to a 1 or a 5 (and appropriately altering the check digit), they can trick the terminal into thinking it's a chipless card and permitting the swipe.

This attack won't work under normal circumstances, because the entire swipe data is sent to the bank to verify. Changing the service code will cause the data the bank gets to be wrong, and it'll reject the transaction "on the back end", as the article you linked to says:

"If the data on the magnetic stripe is altered it might fool the terminal," said U.S. Payments Forum director Randy Vanderhoof. But on the back end, the system would "reject the transaction."

However, merchants have the capability to do "store and forward", aka "offline mode". Slide 24 points out that EMV fails to "Prevent using modified Track 2 in offline mode", which is very true. This happens when the POS is unable to actually connect to the card networks to get an authentication from the bank. Rather than reject all transactions (lost business!) or require calling the bank to get a verbal auth code (lost time! customer confusion!), the business just decides to store all the transactions and forward them later, when things are back online. Since there's no connectivity, there's no way to know whether the data is valid, if the card is over its limit, or any of the other usual safety checks. The merchant accepts the risk of that in order to continue doing business.

Obviously, in this mode the altered track data won't be caught until it's too late, and the transaction fails to forward, bypassing EMV altogether.

... because of the way many retailers are upgrading their payment machines: They're not encrypting the transaction.

This is a separate issue, where the merchant's terminal transmits the card data to the POS in plaintext. Even if the POS then immediately encrypts it (either for store-and-forward storage or to actively transmit), it was still in the clear over one leg of the network, which provides opportunity for compromise. The section of the slides that starts on page 13 address one (of many) attacks on this: Networks shims. If you can put your device or code between the terminal (POI) and the payment app that encrypts it, or between the (non-encrypting) app and the POS software, then you can read off the data as it goes by, undetectably.

The counter to this one is on page 41 and higher: Point-to-point encryption (P2PE). With P2PE, the device encrypts the data itself, using a pre-loaded key. Now, no matter where you interject yourself into the process, you can't retrieve the card data, because it's encrypted all the way to the gateway/processor/card network.

This still doesn't protect you against skimmers (page 39) or attacks on the device's software (page 40 and earlier), but it reduces the attack surface.

  • OK; thanks. The CNN article was a bit misleading in suggesting it was a single vulnerability. Aug 5, 2016 at 5:26
  • @RobertFraser - I wouldn't even call the first one a security vulnerability honestly. The transaction once it gets to the bank, which it would based on the description provided by Bobson, would ultimately be rejected by the card owners bank as being invalid. Its more of a "business vulnerability", since businesses, are willing to accept the risk the transaction might ultimately be invalid.specific limited
    – Ramhound
    Aug 6, 2016 at 9:40
  • @RobertFraser - Agreed. There's also easier and less detectable ways to fake out the POS (some of which the researchers talked about), so I don't know why they picked that one to write about.
    – Bobson
    Aug 7, 2016 at 3:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .