Slashdot Mirror
Security Breach Exposes 40M Credit Cards
The Good Reverend writes "MasterCard International announced today that a security breach at CardSystems Solutions, a third party processor of payment card data, potentially exposed more than 40 million cards. Mastercard is aware of the specific card numbers affected, and is giving its member financial institutions the numbers that may have been compromised. Unlike many of the past high profile cases this one involves a hacker rather than lost packages. CNN Money, the New York Times, Reuters, MSNBC, ZDNet, C|Net, and the Washington Post are also covering the story."
About 25 MILLION of the 40 WAS NOT a MasterCard, so there are a WHOLE bunch of credit card providers who like leaving you in the dark here people.
Have to agree here. I work for a large mailing house company which processes client data and sends out bank statements and tax details and all sorts of other private information.
Having a in depth security background, I can safely say that the security of this place is shocking. The guys handling this sensitive data are just kids straight out of uni. The banks etc themselves can go to great lengths to protect their clients data, but then they outsource to 3rd parties and hand over all their data to be processed.
Posting anonymously for obvious reasons.
It's worth mentioning that they're hiring people with VMS and WindowsNT experience. Small wonder the malicious code got in there.
Direct away from face when opening.
I think we all have to worry anyway. This kind of shit happens all the time. They're going to find the people responsible for these, and the corporations that allow it to happen will get off with only a bit of bad publicity. That's the real tragedy. There ought to be a law that if you are going to retain someone's personal information then you are responsible for keeping it safe. Same as I'm responsible for keeping my PIN number safe.
Well, not really stupid, just outdated.
The system you're describing is called Finread.
Finread is more secure than previous solutions because its smart card reader is "smart". It has a pinpad, a screen, a Hardware Security Module and a smart card reader. It is designed to work with EMV smart cards (a public-key scheme). You put your card in the reader, the screen displays the amount and the recipient, you type your secret pin on the pinpad and voila, payment's made.
Since the reader "smart", the remote payment processing system can bypasses your spyware-infested Windows machine to communicate directly with the card through a small, dedicated piece of hardware that is much easier to secure than an computer. Keyloggers and spyware are inefficient because your computer does not process any sensible piece of information. It's like opening an bi-authenticated SSL channel between your card and the Visa or MasterCard processing systems.
Finread is far from perfect, but much better the current situation. The only drawback of Finread is that it is so good that when it will be cracked, banks will probably manage to claim that everything's fine for a long time.
Now, of course, for lost tapes, we still need something else.
Nobox: Only simple products.
It's about time for the financial services industry to step up and take responsibility for designing a payment infrastructure that can accomodate the current threat environment. A sixteen-digit reuseable number can't provide adequate security, even when coupled with real-time billing address and CVV2 tests. Payments need to be authorized individually by the accountholders, and these authorizations need to be tied to a specific date, time, merchant, and amount (or in the case of recurring payments, a time span, number of payments, and maximum aggregate amount). In this scheme, leakage of an account number doesn't connote authorization for payment--and leakage of a payment authorization doesn't enable re-use by others.
It will be hugely difficult and very expensive to make this change, of course, as it involves replacing a great deal of infrastructure. But ultimately it will be required due to the simplicity of fraud using today's technology. It's gotten to the point where most of the difficulty and expense isn't the technology for payment authorization; it's instead the cost associated with the changeover itself and with retraining consumers and merchants.
So, from where I sit, it looks like the costs of fraud being absorbed by the financial services industry (and, of course, being passed on to consumers in the form of higher fees) aren't being offset by a decrease in the eventual cost of making the system secure. It's time for the financial services community to take responsibility, then: accept the fact that it will be difficult and expensive to make the change, but also accept its necessity and inevitability.
Not to mention that a truly secure card reader would cost a lot more than $25. $150 would be much more realistic. To be even somewhat secure, it would need to at least have a display and its own network connection, which adds quite a bit to the cost.
No a `fully secure' card reader costs $25 today and expect prices to keep falling as demand goes up. To be somwhat secure? You still don't seem to get the idea of the signing operation of a transaction done on a card. I suggest you read up on how a JavaCard works.
Customers generally don't need to ship stuff to 20 different addresses, and it's not difficult to call your bank and have them add another authorized address. Most places will still ship to an alternate address, they will just call you first to confirm. Having to use special card reader hardware would be much more of a hassle.
No customers don't have to ship items to 20 addresses, but I'm not about to to register all my acquaintances' addresses to the credit card, just because I want to send them gifts directly.
Your system has exactly the same problem. There is no foolproof way to identify a person remotely. Plus, your system is now susceptible to spyware: put some software on the customer's machine to hijack the card reader and you can do what you want with the credit card. If anything, it's LESS secure.
I believe you're just trying to knock me here, rather than actually first read up and understand how the system works. Read up on how a Java Card works. I'll explain once more for your benefit. The cryptographic signing operation takes place on the card. Your private key is stored on the card and there is no way you can extract the key from the card. You can only present a transaction to the card and have it signed, and retrieve the signed transaction. The signature is only valid for one transaction, done by a particular vendor only, because the signed data contains the transaction ID, the price which it's paying. The signature-request which is supplied to the card contains the price the person would pay for, the vendor details and the transaction ID. This is displayed *on the card* before a customer makes a payment by choosing an option *on the card*. These cards will not be significantly more expensive to manufacture in quantity. Remember card sized calculators? That was back in 1980.
No the system does not have the same problem, nor is it susceptible to spyware. You can hijack a card reader, but you can't hijack the card itself which needs to do the signing after reading the users' input *on the card* which is only powered by the card reader, which also provides the reader interface for communicating with the PC. The card reader is otherwise stupid. No other software on the PC has the private key to do this signing. Even if you were to tap the wire communication, you still cannot fool the system. If you do not follow this, I suggest you read up on even user land items like PGP Corporation's introduction to cryptography which should be reasonable for a newbie to follow. Read on digital signatures and how they are not susceptible to man/monkey in the middle attacks (when the card's public key is known and trusted by the bank), which is exactly what you're claiming by hijacking the card reader.
Banu