Security Breach Exposes 40M Credit Cards 304
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."
RTFA PEOPLE (Score:3, Informative)
Not just mastercard -- VISA, etc. (Score:1, Informative)
Re:Proves that the hackers... (Score:5, Informative)
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.
cardsystems.com/careers.html (Score:4, Informative)
Re:US numbers only? (Score:5, Informative)
Re:The card number / expiry-date system is stupid (Score:3, Informative)
The system you're describing is called Finread [finread.com].
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.
Re:Proves that the hackers... (Score:3, Informative)
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.
Speaking as a Merchant... (Score:1, Informative)
There seem to be any number of companies out there who want my card acceptance processing. (I get cold-called once or twice a month.) A lot of them seem to be resellers for the big national processors. They *ALL* compete on price. I've never had one of them even mention security procedures.
And actually, as far as I am concerned, the security of my processor is not my problem. As long as my terminal software isn't an arcane mess, I don't get any bogus approvals, my legitimate transactions get transmitted to the card companies on deadline, and the cash winds up in my bank account when it's supposed to, then I'm satisfied.
IMO the security issue belongs to the card companies. They're the ones that wind up paying the cost of fraud, and if they don't like the way a processor does its security, then they should not allow it to handle their cards.
(And as a practical matter, I've usually gone with the processor recommended by my bank. At worst, it only costs a bit more, while at best it gives me another hammer (my banker) should there be a dispute. And it means I don't have to deal with issues for which I have neither the time nor the expertise.)
Re:being a site full of geeks (Score:1, Informative)
Visa and other credit card companies have recently been getting VERY demanding regarding security practices. They have literally forced everyone that processes payments for them to secure their networks, or face losing their processor license, and with it, all of the customers that use Visa.
The security requirements are part of a new program called CISP (Cardholder Information Security Program), which requires safeguards that are at least as demanding, if not more so, than federal reserve requirements for banks. You can read more about CISP here. [visa.com]
Some of these requirements are:
- All cardholder data is encrypted whenever stored.
- Firewalls need to protect perimeter networks (of course).
- All passwords used by sysadmin or developers need to be changed on a regular basis, and must adhere to strict guidelines about length and password strength. This forced us to deply LDAP.
- OS level auditing must be turned on, and all employee access to any cardholder data must be audited and stored in a secure location.
- All hosts on the network must be scanned regularly using Nessus or other commercial scanning tools.
- Security patches must be applied regularly, based on the results from the scans.
- Intrusion Detection Systems must be installed on the network.
- No insecure protocols can be used such as telnet, rlogin, etc. All communication must be secured using SSH or some other type of encryption.
- There are also a ton of safeguards to prevent developers from sneaking malicious code into production systems (ala Office Space). No one developer can modify code without another developer signing off on it, and a security officer approving the code before it is released from development to QA, and from QA to production.
- Different teams of developers work in Dev, QA, and Production in order to prevent any one team from being able to hack the system.
This all adds up to millions in extra costs for the credit card processors. It has been a huge burden on the industry. These safeguards are a good idea, but the problem is that the credit card system is only as good as it's weakest link. The company I work for might be as secure as humanly possible, but because some processor that's a hell of a lot bigger than us in Arizona got hacked, the security at my company does those people no good.
Anyway, I'm posting this anonymously so you can't tell where I work at.
Re:The card number / expiry-date system is stupid (Score:3, Informative)
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 [pgp.com] 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.