Target's data breach bigger than first thought – more than 100M records
nakedsecurity.sophos.com
nakedsecurity.sophos.com
I wonder why they're not using this information to contact their "guests" directly? Why should I need to read about this revelation on HN, when they know everything about me.
[0] http://motherboard.vice.com/blog/target-knows-you-re-pregnan...
In comparison, a letter to you from Target directly detailing their failure - not so good. no doubt they’re avoiding this unless utterly forced to.
This is why we must push back against companies who not only want to "track everything" about their customers, but about their non-customers, too!
You would have had to have "interacted with Target", meaning that you gave them the information in the first place.
Of course, Target will try to track you even if you don't provide them with contact information. E.g., if you use the same credit card across multiple visits, they won't have your contact information or even your full credit card number (which they aren't allowed to store). But they will be able to analyze what you bought over time, and that's valuable.
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).
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.
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).
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.
... well no. 'Guest' is just how Target refers to customers, its just corporate speak.
In 2015, if you implement EMV, and take a chip-and-pin transaction at the point of sale, and the card itself is counterfeit, then you won't be liable. If you don't support EMV, the liability will be the same as it is today. If you do support EMV, and the fraud is something other than a counterfeit card, the liability will be the same as it is today.
It's almost as if they designed the incentive to create a talking point when selling the EMV hardware to retailers, without actually shifting any meaningful liability away from them, so the card brands and banks can continue suffering none of the losses due to fraud outside their merchants' reasonable ability to stop.
Having to deal with a stupid little machine terminal every time I'm in a restaurant is just obnoxious.
They were uploading encrypted PIN blocks to their payment processor, and the bad guys captured those along with the mag stripe data. But encrypted PIN blocks are useless to a hacker. Target can't decrypt the PIN-blocks. Only the payment processor has the key. Unfortunately, this point seems to have escaped some of the media morons, who would rather write scare headlines than get it right.
PINs are entered on separate keyboard devices, known as PIN-pads. A PIN-pad is a tamper-resistant subsystem that can be programmed to prompt the customer to enter the PIN on its separate little keyboard. The PIN-pad then encrypts the PIN, using keys which are preloaded by the payment processor, and provides the encrypted result to the POS terminal.
PIN pads have been hacked† in the past, but the methods employed require physical access to the POS terminal and are thus no where near scalable to the level of the Target hack.
†http://fraudwar.blogspot.com/2007/02/could-arrest-in-stop-an...
And I doubt Target was storing the data, as they don't have a legitimate business need. Businesses that do have such a need, such as hotels and car rental companies, are allowed to keep the data, but only subject to stringent security.
It seems likely that the hackers broke into Target's network and found a way to install malware on the POS terminals, designed to tee the credit card info off to the hackers in real time (or perhaps log it to disk, where the hackers would come by and fetch it).
This is a company that loves to try and predict customer behaviours by using massive data-mining techniques. I would be surprised if they didn't store any and all data they get their hands on, especially if it could be used as an additional table key. For background, I recommend this article, which is one of the most interesting works I've seen in the last ~decade:
http://www.nytimes.com/2012/02/19/magazine/shopping-habits.h...
Both features are possible without actually storing the card number; one-way hashes to do the receipt lookup, and tokens to do the refund, but how likely is that?
I think in Target's case it will turn out the hacker was sniffing network traffic on the internal network, and just pulling every transaction right off the wire.
>Both features are possible without actually storing the card number; one-way hashes to do the receipt lookup, and tokens to do the refund, but how likely is that?
There is a company, Shift4† ($-sign on a US keyboard, get it?), who provide credit card processing service to smaller merchants. Shift4 itself is not a payment processor. Rather, it provides an intermediate layer standing between the merchant and the payment processor(s). A prominent feature of its service offering is tokenization: the ability to refer indirectly and opaquely to specific transactions and card accounts. It removes the need for the merchant to store card details. Shift4's tokens give the merchant a way to refer to past transactions and card accounts without having to store card details.
You write them to a card and then you have a dupe that can be used in card-present credit card transactions. These dumps are all over the underground forums, they are easy to buy - that is, afterall, how Target found out about the hack.
†http://en.wikipedia.org/wiki/Derived_unique_key_per_transact...
I'm curious if they stored the information from the magnetic strip on the license and, if so, was that information stolen as well? Also, if they did, is it legal for them to do so.
I haven't even heard anyone from the news even bring this up, but I think it would be much more serious than the cc data.
edit: To further clarify, if you use your CC, you have to give the merchant or processor all the data required to make a purchase. The protocol/idea itself is broken, just like automated ACH by an external third party.
edit 2: To go further, think about when the social network sites used to ask for thr username and password you used in order to login to third part services to 'invite your friends'. That was clearly a security mistake at the idea level. Now most services hardened up a little and offer revokable API access so that your account credentials are not required by a third party and usually even access limits can be set on a per API key level basis.
If transaction confirmations took less than 500 milliseconds and had at least two confirmations from a network that had some form of insurance against double spend (rare and very noticeable) and identity theft (more common, but also noticeable) and auth token theft (relatively common). You could have something that looked like a general purpose internet mediated payment mechanism of sufficient (but not perfect) security; that would be relatively backwards compatible with existing infrastructure and resistant to attacks that merely depend on access to stored data rather than controlling a distributed ledger.