Encrypted PIN Data Taken In Target Breach

New submitter danlip writes "Target has confirmed that encrypted PIN data was taken during its recent credit card breach. Target doesn't think they can be unencrypted by whoever may have taken them, because the key was never on the breached system. The article has no details on exactly how the PINs were encrypted, but it doesn't seem like it would be hard to brute force them." Another article at Time takes Target to task for its PR doublespeak about the breach.

Re:Why are they storing this data anyway?

[Tool Man]

Nope, horse-puckey. This would be the same PIN data that their PCI compliance *cough* would disallow from storing after authorization for a transaction, just like the CVV codes which I think also got nabbed. Now, it is possible that they were all captured "in-flight" and not being stored against the rules, but it is very much verboten to keep even with encryption.

Re:Time to ask the bank for a new debit card and P

[Todd Knarr]

That depends. How understanding will your landlord or your bank be when your rent or mortgage check bounces because the day it was deposited somebody ran up charges on your debit card that emptied your bank account? Sure you'll be able to dispute the charge, but that didn't stop the checks from bouncing between the time it happened and the time you got to the bank to fill out the paperwork on the fraudulent charge. Same if you're at the end of a trip and go to pay your hotel bill and your credit card's over limit because of fraudulent charges. Sure you'll be able to dispute them, but that doesn't make the hotel bill magically paid.

Re:Can encyption experts chime in?

[hargrand]

You're assuming the PIN was in any way related to the 3DES key. That's almost certainly not the case. More likely, Target requests a transaction key from the bank which is then used to encrypt the PIN and sent the encrypted PIN to the bank. The bank then decrypts the PIN using the 3DES key and verifies the PIN.

They probably should switch to RSA or some other public key algorithm. With 3DES, both parties need to share the key. With RSA, there is a public key and a matched private key. If the public key is compromised, it's no big deal. Since the bank retains the private key and doesn't share it, it's at least theoretically more secure for this kind of transaction.

Re:We'll know soon

[Above]

I hate to reply to my own post, but I appear to be modded "Insightful". The correct mod selection was "Funny".

*sigh*

Re:Why are they storing this data anyway?

[snowraver1]

I have been doing card processing for a living for 7 years now. The pin, of course, has to go over the wire along with the track2 data. How exactly that happens can differ greatly though. Larger merchants are more likely to use some sort of middleware processing software, and that introduces weaknesses. In many cases communication between the POS and middleware is plaintext. Scooping this data up would be trivial, but PCI mandates that unencrypted data has to be segregated off the network from non-PCI stuff. This makes things a bit trickier for an attacker.

As for Target, here's my take: This is the only information in the press release:

The PIN information was fully encrypted at the keypad, remained encrypted within our system, and remained encrypted when it was removed from our systems.

To help explain this, we want to provide more context on how the encryption process works. When a guest uses a debit card in our stores and enters a PIN, the PIN is encrypted at the keypad with what is known as Triple DES. Triple DES encryption is a highly secure encryption standard used broadly throughout the U.S.

If they were using "true" end-to-end encryption, there are no known attacks other than card skimmer magic*. If that was the case, there wouldn't be much of an investigation, as the facts (and scope) would be pretty clear.

That leaves a network packet monitor attack, a database related breach/attack, log file snarfing (depending on the vendor, log files can contain a LOT of data.), or something I'm not thinking of.

I find it odd that they say that pins have been pilfered, but not the card numbers. That, to me, suggests a DB related attack, and the attackers only got the pin table/columns. A list of pin numbers though, of course, is completely useless (8374 - Here's a free one) on it's own. Decrypting them should be trivial, given the limited number of possible pin numbers, even if the table was salted. But again, what would be the point. I'm guessing that the next release will say that card numbers were compromised as well.

As for the 3des part, It just doesn't make any sense. As other people have already said, 3des is symmetrical, so saying they don't have the key is impossible. My guess is that they are actually using SSL (which could then in turn negotiate a 3des key). If that is the case, then each session key would be unique, and target would never have "access" to it as it would only exist in RAM.

To my knowledge. I'd be happy/interested if someone could prove me wrong here.

Re:We'll know soon

[Fnord666]

Except that they were almost certainly using ANSI PIN blocks which XOR the card number into the data before encryption so that two identical PINs do not encrypt to the same cipher block. In addition, the terminals may have been using DUKPT [wikipedia.org], which is short for Derived Unique Key Per Transaction. This means that each PIN block is encrypted with a different key. Brute forcing one PIN block will not yield any information about the next one.