[deathanatos]

> [Target] won't have […] even your full credit card number (which they aren't allowed to store)

They won't have my credit card number? Wasn't how got to this very discussion because they have my credit card number?

> So far, Target says, it's determined that the breached data includes customer names, credit or debit card numbers, card expiration dates, and CVVs (cards' three-digit security codes).

[cynwoody]

They're only permitted to keep the full credit card number for as long a business need exists. For a hotel or a car rental agency, that might be days.

But for a retail transaction, it is a couple of seconds: submit the charge, mag stripes (and maybe PIN-block) and all. Then receive back the accept or decline. Just a simple HTTPS request. They are only allowed to keep part of the PAN beyond that time frame (the BIN and the last four if memory serves). No expiration date. And no CVV (the one that authenticates the mag stripe data, not the three or four digit code you enter for online transactions).

What the hackers must have done is to install malware on Target's POS terminals that was intercepting the full mag stripe data and making it available to the hackers. They must have gained free reign on Target's corporate network, allowing them to access the POS terminals remotely. The marketing database breach was just frosting on the cake.

[coleca]

The interval Target held the cards was probably longer than a few seconds. Depending on how they do settlement they may need to keep the PAN around longer until they settle the transactions. Some retailers do it real time (right after auth) but many do it in batches at the end of the day, overnight. That first message only authorizes a transaction. The money isn't drawn from the account until a settlement message comes through.

Target also does not have a loyalty card program. This means that the only way they can track individual purchases would be via a credit card. Target has very sophisticated marketing systems. They may have convinced their auditors that they need to keep the cards around longer because that is a legit business use. I would hope the cards are tokenized in those systems but you never know.

Also, the hack was most likely not on the POS system but on their payment switch (software for payments routing not to be confused with a network switch). There would be one central point where all their transactions are funneled to their various payment networks. This would be the place to intercept 40-110m transactions. At the individual store level it would be much more difficult to compromise that many systems across thousands of locations versus one central point and get the data out. Smaller retailers will connect their POS systems directly to the banks but large retailers usually have private dedicated circuits to their payment providers that flow through a payment switch. The POS systems connect to that central switch not the payment network.

For those predicting the imminent demise of Target, go back and look at a historical chart of how TJX's stock has performed since their breach in 2007 (mid teens to over $60/share now).

[cynwoody]

> Also, the hack was most likely not on the POS system but on their payment switch (software for payments routing not to be confused with a network switch). There would be one central point where all their transactions are funneled to their various payment networks.

Interesting. That strikes me as a rather dumb way to architect a system. Much better is a simple HTTPS request direct from the POS terminal to the payment processor. That way the bad guys have to hack the individual terminals. Of course, given a little automation, once they've figured out how to compromise one POS terminal, the rest are just a bunch of parallel loops away.

Ten or 12 years ago, I implemented POS interfaces to Fifth Third and Concord EFS. The POS in question was designed for use in individual retail stores, where there might be half a dozen registers.

Both Fifth Third's and Concord's interface took the form of a single HTTPS request to a designated URL. As I recall, Concord's was by far the simpler interface, requiring only the obvious data. Fifth Third's had a lot of legacy nonsense, requiring you to figure out what you really needed to provide. Both had a POS interface certification process, wherein you needed to hook up to a test system and correctly process a bunch of test transactions.

Fifth Third did have a batching function, but it did not require the establishment to store transactions client-side. Rather, the batch was accumulated on the payment processor's server. The POS system could request that a batch be closed (at the end of the business day, for instance). There was also a web login that the store manager could use to check on the status of the day's charges and some number of closed batches.