Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
Security Encryption

Encrypted PIN Data Taken In Target Breach 213

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.
This discussion has been archived. No new comments can be posted.

Encrypted PIN Data Taken In Target Breach

Comments Filter:
  • Subject line says it all :)

  • by Anonymous Coward on Friday December 27, 2013 @07:45PM (#45801549)

    Is there a good reason for keeping this that I'm not seeing?

    • They don't (necessarily) have to, if the attack was ongoing (which it sounds like it very much was) then the attackers could have retrieved the PINs in transit.

      • As I said above, why are the chip & pin machines not designed to avoid this? Surely the keypad should operate without firmware, and be responsible only for sending the key presses to the card. The card's chip can then generate a response from a hash of the challenge and the PIN, and only then send the data off the card/key pad, and into the system controlled by firmware.

        • In the US they generally don't use chip & PIN. The stolen PINs involved are for bank ATM cards without chips, not PINs for credit cards with chips.

    • Terminals encrypt PIN data inside the device. The terminals they use are PED certified. DUKPT is used, and the data should be safe. The PIN block should stay encrypted all the way to the processor. If it is decrypted it should be done in an HSM. The malware was most likely scraping memory on the POS and grabbing track data as it was passed from terminal to the POS. Then they somehow exfiltrated it out. Obviously they weren't using encrypted terminals. I don't think target stored this data centrally. Most l
  • by Above ( 100351 ) on Friday December 27, 2013 @07:46PM (#45801561)
    When 25% of the pins encrypt to one string, and 25% to another, we'll know they used a symmetric cipher with a fixed key, and that one batch is "0000" and one is "1234".
    • Yes but if that's the case they don't even have to crack the encryption, they've already got the PIN for 50% of the cards!

      50% of 4 million cards (or whatever the number was) aught to be more than enough for anybody.

    • Re: (Score:2, Insightful)

      by Above ( 100351 )

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


    • Re:We'll know soon (Score:5, Insightful)

      by Fnord666 ( 889225 ) on Friday December 27, 2013 @10:38PM (#45802625) Journal
      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 [], 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.
      • by Above ( 100351 )
        You should be modded Insightful.
      • Except that they were almost certainly using ANSI PIN blocks which XOR the card number into the

        You're assuming competence here when every aspect of this breach has demonstrated incompetence. I happen to know what Target considers "encrypted" PINs, and it's nothing so elaborate. They are referring to the drive-level encryption mandated by Sarbanes-Oxley. They are correct in that the keys to decrypt the drive is tied to the hardware and that the only copies are stored on a remote server. However, what they aren't telling you is that this breach didn't consist of someone walking into a server closet and

  • by postmortem ( 906676 ) on Friday December 27, 2013 @07:47PM (#45801573) Journal

    How hard it would be to decrypt, knowing that each pin is exactly 4 digits?

    I would think if salting was not using, it is just a matter of the time.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      They are encrypted using 3Des using the following algorigthm. []

    • How hard it would be to decrypt, knowing that each pin is exactly 4 digits?

      It would not be difficult. But what is the point? The PIN is only useful if you physically swipe the card. You don't use a PIN during a "card not present" transaction, such as an online purchase.

    • PIN blocks are encrypted using PIN block format 0 []. In this format a portion of the account number is XORed with the PIN block prior to encryption. The result is that for two different accounts with the same PIN, even if they are encrypted with the same key, the resulting encrypted PIN blocks will be entirely different.
  • by sribe ( 304414 ) on Friday December 27, 2013 @07:50PM (#45801589)

    The article I read stated that the key necessary to decrypt the data was never on the systems which encrypted the data, then went on to state that the data was encrypted with triple DES. Oh my lord. Which is it? Symmetric or asymmetric encryption?

    • by taustin ( 171655 ) on Friday December 27, 2013 @07:55PM (#45801631) Homepage Journal

      It depends on what was compromised. Normally, debit card stuff is encrypted on the pad you swipe the card in. If the pad was wasn't what was compromised, then the key wasn't on what was, because that's the only place the key is kept.

      (Earlier reports claimed the pads had been compromised, but that smelled like bullshit then, and even more like it now.)

      • by sribe ( 304414 )

        It depends on what was compromised. Normally, debit card stuff is encrypted on the pad you swipe the card in. If the pad was wasn't what was compromised, then the key wasn't on what was, because that's the only place the key is kept.

        Ah, thanks for the clarification.

    • Point of Sale terminals keep their 3DES encryption keys in firmware within a tamper-resistant module. Even with advanced technology like plasma ablation and electron microscopy, it is believed to be impractical to extract the key. The keys are loaded by a courier who swipes special cards while the device is in maintenance mode. This permits the POS stations to be used over an insecure line to the payment processor, and cleartext is never present anywhere outside the sealed module, from which the key cann
  • To me this whole fiasco smacks of an inside job, or at least having a compromised employee/contractor. Certainly other scenarios are plausible, but IIRC they got into a system that pushed corrupt firmware to the card readers. I am assuming Target uses such firmware to put their graphics on screen, plus other Target specific things (like discount ts for target debit card users).

    The number of people with knowledge of how to change the firmware is probably a pretty short list. When crossed against the list

    • Re:inside job? (Score:5, Interesting)

      by Rhyas ( 100444 ) on Friday December 27, 2013 @08:14PM (#45801801) Journal

      They didn't get anything onto the card readers from all that's been published publicly so far. Most card readers these days will encrypt the pin *before* sending the data to the terminal. Thus, only getting encrypted pins.

      Given that the terminals run windows, it's not that difficult to get some malware to spread to them from a central source. Could still be an inside job for sure, but none of the details published yet can confirm that for fact.

      • by Bert64 ( 520050 )

        Windows corporate networks almost always operate on the idea of protecting the perimeter, and leaving the inside horrendously insecure... For something like a retail store, where the general public have physical access to the building that idea breaks down very quickly... You only need to have momentary access to a network socket/cable, and these will often be available at random points on the shop floor or at the very least at the back (i.e. facing the customer) of the pos terminals...
        Once you're on, chanc

    • by swb ( 14022 )

      I've heard from a Target insider that they do believe it involved an insider.

      What I don't understand is even if it was, don't PCI standards, Sarbannes-Oxley, internal financial controls and the sheer IT scale of company of Target's size mean that any random insider would not have broad enough administrative access to compromise enough systems to pull this off?

      In other words, someone with high level data network access (network engineer) wouldn't have access to databases, applications, and operating systems,

  • OK, that's fine, but how is PIN code useful? Can't you just order on the web with your credit card without any PIN code? Can't you just pay for speedways in at least France and Italy without PIN?
    To be honest I am wondering why there is even a PIN code on those cards given there are so many ways to use them without entering the PIN code.

    • by Em Adespoton ( 792954 ) <> on Friday December 27, 2013 @08:12PM (#45801775) Homepage Journal

      OK, that's fine, but how is PIN code useful? Can't you just order on the web with your credit card without any PIN code? Can't you just pay for speedways in at least France and Italy without PIN?
      To be honest I am wondering why there is even a PIN code on those cards given there are so many ways to use them without entering the PIN code.

      The trip a card purchase takes from your physical card to the merchant bank is actually pretty convoluted -- the simplified explanation is that a card purchase with PIN has a lot fewer safeguards and security checks than an online purchase with card, address and CV only. For card purchases where only the number is used, the vendor assumes a HUGE amount of liability. It often makes sense for fast food vendors and such, where the transaction values are small and they get a significant uptick in sales for shorter transaction times, but for purchasing big ticket items, you either do chip+pin or track 1 data plus second factor (usually stored by the vendor).

      So the even shorter answer is: PIN codes mean relative anonymity. Without the PIN, you need to provide other PII at some point in the transaction.

  • I could be missing something here, but by my understanding PINs are usually only 4 digits long. I would think that the people who were able to snag the cards that they correspond to could probably come up with a clever way to figure out the PINs on most of these cards without ever needing to decrypt the data. I recall not long ago seeing a publication of the frequency of PINs in use today; it would seem that they could probably gain access to a significant share with just that list alone.
  • Why combine something you know with something you have? I thought only banks stored pins?

    • by EvilSS ( 557649 )
      The PINs could have been captured in flight. They can't be stored, but they still need to make their way from the terminal to the bank for verification.
      • by ljheidel ( 72508 )

        I know for a fact that one of the items on the PCI list for CC transactions is 'no storage of CVV data.' If Target was indeed storing the PIN numbers, I feel like they have some real 'splainin to do about that one. However, based on the fact that they're obsessive about data mining, I wouldn't put it past them. "Why do we need to keep the PIN numbers?" "I dunno, but we can." "Okay, let's do it."

        However, if the data was stolen 'in flight' as EvilSS suggests and it *is* encrypted (and based on the prevar

        • by EvilSS ( 557649 )
          They are required, by standard, to be encrypted at the POS terminal. CC #'s are not because they can be stored by the merchant. Should they be? Hell yes but I didn't make the rules.

          From my experience working with PCI compliant companies, the CC info is usually kept on a completely separate network from the normal corporate network. It usually routes back to a central office or branch office before making it's way to the payment processor in large companies (small mom & pop it probably dials/VPNs di
    • Why are you claiming that the PINs were stored?

  • Hope Target's systems used a salt when creating the 3DES.

    If the Triple DES used a salt, then good, it will make it much more likely the PINS are secure, because then the hackers would have to brute-force trying a salt value, then all possible pins for 1 of the Triple DES encrypted PINS, which would take longer.

    If the salt was unique for each PIN, then that would be the most secure ( but I do not know how a little machine where people give their pins could do that )

    If no salt was used, then might be another

    • Given advances in both ASIC and GPU design, I wonder how long it would take to brute force a card these days - or brute force the top 20% of all numbers for instance. GPUs have massively parallel execution which could be brought to bear on the problem.

      That said, over here in Aus, transactions under $100 can be performed just by waving your card near a terminal - no pin or CCV required. If they can clone the card details onto those sorts of cards, then they can use 'smurfs' to run around hitting 1,000s of sh

    • (sends you back to Encryption 101)

      Hashing relies on salt for security. Encryption does not.

      Passwords are hashed instead of encrypted because you want to make it near impossible to reverse the process and discover the original password. In fact, you hash, because you are simply not interested in being able to reverse the process. You then use custom salt along with the hash step to make pre-generated rainbow attack tables useless. And to prevent the breaking of one account to instantly grant access t
  • DUKPT (Score:3, Informative)

    by Anonymous Coward on Friday December 27, 2013 @08:12PM (#45801777)

    PIN are supposed to be encrypted on the terminal (not on the POS computer but the actual card reader/terminal) using Triple-DES Derived unique key per transaction (DUKPT - ).

    So no the PINs are safe unless the card terminals have been hacked too.

  • Only "weakly encrypted" PINs. How do you "encrypt" a four-decimal-digit PIN? Even if they only had PIN hashes that were as yet uncompromised, it wouldn't offer much protection. if Target changed policy and invalidated your card immediately after you entered the first wrong PIN, the crooks still stole 40 million cards and would have scored a list of about 4000 working card numbers. At least if the PINs were required to be base-64, the crooks would only find a few.
    • by AHuxley ( 892839 )
      Yes the users cards would have some long numbers in the mix when used with the pin to send back to the bank...
    • Only "weakly encrypted" PINs. How do you "encrypt" a four-decimal-digit PIN?

      The same way that you protect any other plain text of nearly any length at all. You generate an encryption key (56bit DES, 112bit 3DES, 128bit AES or 256bit AES) and encrypt the plain text with that key.

      The only way to get the plain text back is to brute-force the key (assuming that the algorithm is well designed, properly implemented, and that the key can't be leaked in some other fashion).

      Here is an example for you: Please
  • by AnalogDiehard ( 199128 ) on Friday December 27, 2013 @09:01PM (#45802115)
    What was Target collecting credit card numbers AND PIN numbers for? What business purpose did they need that data for? Why has no one raised this question? They have just created a huge credit theft problem for their customers. This is a shining example why businesses should not maintain any database of sensitive customer information.

    I already suffered identity theft and credit card theft in the past and I'm not at all anxious to go through that again. I'm taking my business elsewhere. In fact I may avoid large national chains for this very reason.
  • Can anyone tell me what operating system and software that Target uses?

    I'd really like to know what exploits this software has and if any other store uses them so I can avoid shopping there.

    I think retailers and wholesale clubs ought to be transparent in what operating systems and software they use for their POS system and then list the vulnerabilities they found with an code audit and how they plan to fix them.

    This ought to be a law, so consumers can be protected from retailers and wholesale clubs who don't care about their privacy and credit card and debit card data and just use operating systems and software with exploits in them that they never tested nor figured out how to fix.

    I think the same should be done with websites as well.

    Am I right here or wrong?

    • by Shados ( 741919 )

      If they're like virtually every other retail chain in the world (short of maybe Amazon, but do they even count?), its probably not an issue with the particular software they use, but that they use old, outdated, or poorly configured versions.

      These companies run -countless- systems, for their ERP, CRM, CMS, a bunch of other 3 letter acronyms, stuff to integrate all of them, stuff to integrate the stuff that integrates them, all those things use different operating systems, need to be in sync to be "supported

    • I'd really like to know what exploits this software has and if any other store uses them so I can avoid shopping there.

      People. That's the exploit. You shouldn't shop anywhere with people, they are incredibly fallible and sometimes quite evil bags of mostly water.

      Sorry but if you're looking for perfect security you won't find it anywhere. The NSA couldn't keep control of it's own people, how is some dumb chain store.

Technological progress has merely provided us with more efficient means for going backwards. -- Aldous Huxley