Slashdot Mirror
How to Avoid a Target-Style Credit Card Security Breach (Video)
Wayne Rash has covered IT as a reporter and editor for over 35 years. NPR, Fox Business News, and NBC all call on him as a technology expert. A few weeks ago he had an article on eWeek titled How Target's Credit Card Security Breach Could Have Been Avoided. In this video, Wayne tells how you (or your business) can avoid being targeted by miscreants out to steal credit card data. It turns out that the security measures he advocates for businesses are common in other parts of the world but haven't hit the United States quite yet. But don't despair. There are things you can do right now, as an individual, to limit your potential losses from card number thefts. Still, the long-term fixes to the security vulnerability that bit Target need to be made by merchants and card issuers, some of whom are already transitioning to cards and card readers that use EMV chips, and some of whom aren't quite there yet -- but might speed up their efforts after seeing what happened to Target.
... is all about DB security, simply do not allow any access to the DB from the webserver at all. Assume your webserver is already compromised and build from there, is not difficult to do.
Last place I worked, my boss had a pet website thing written in the usual way - client web code running on the web server that directly read DB tables. When he told the admin guys to put it live they told him they couldn't - there wasn't access to the DB from the webserver, so he told them to "just punch a hole in the firewall"... and they told him there was no firewall. There was no physical cabling between these servers.
That's the way to do it. you always go through a middle box, and you create an API on that middle tier that your web code can access, and that is tightly locked down. Then you also expose your DB as an API (via stored procedures) that only the middle tier can access.
Then, if (ha! when) someone hacks your web server, all they can do is call the API methods on the middle tier, and even if they manage to hack the middle tier too, all they can do is call the DB API methods. None of those methods will have a routine that returns more than 1 CC data, at best.
This stuff isn't hard, but requires a little more discipline than web devs are used to. It also requires that the only code you run on the web server is presentation stuff, no slapping it all on there like most code and frameworks guide you into doing.
Nothing else needed, why are we even discussion this?
Not everyone wants to walk around with $1000+ in cash in their pocket so they can make a big purchase. And when you lose cash, it's really lost to you - if someone steals the cash from your pocket, there's little hope of recovery unless they happen to catch the thief, at least if they steal your credit card, you can report the fraud and get your money back.
Also, always use a backup card when traveling to higher fraud areas. We vacation in Mexico regularly, for a while every time I went I would get hit with fraudulent charges after getting home. I switched to using one of our backup credit cards while on the trip, then calling the bank when I got home. I would tell them that I was traveling and suspect that my number might have been compromised. They have been more than happy to cancel my old number and reissue me a new one. A few days later I had a new card and was ready to travel again. No issues with fraud since we started doing that.
1. The card readers still have to make it to a compatible merchant services provider, so not usable everywhere. In Canada, its pretty rare for any small to large service providers not providing readers for chip cards. Only really little merch's that accept square or paypal haven't made the switch, or some big box american stores who's unified infrastructure apparently makes this too hard for the effort.
2. The chip is a digest encryptor to my knowledge. I don't know if anything besides the merch and most likely an account number are on the card unencrypted (or should be anyways), but yes, any and everything usable to track people's unique info can and will be used to track you. That is a 'freedom' long lost.
3. Wireless can be an issue (my Android phone's NFC pings when its laying on the wallet) but realistically, all companies supporting wireless transactions support VERY LOW payment methods, like $50 and most likely rejecting duplicate purchases. I bought movie tickets yesterday with pay wave and I then went to the popcorn stand and waved again. The second time, it required chip usage, so there's probably logic to cap the potential losses of fraudulent wireless payment charges.
Bye!
Nothing else needed, why are we even discussion this?
Not everyone wants to walk around with $1000+ in cash in their pocket so they can make a big purchase. And when you lose cash, it's really lost to you - if someone steals the cash from your pocket, there's little hope of recovery unless they happen to catch the thief, at least if they steal your credit card, you can report the fraud and get your money back.
Um you didn't even point out the obviously flaw in today's day and age of using cash especially among slashdotters. So, I should stuff $2,000 in an envelope with purchase order and mail it to NewEgg to purchase the parts for my next gaming rig? NOT! "I'm sorry sir, but there was no cash in the envelope you sent us. Can you try re-sending it?" It really drives me nuts when snarky people are like just use cash! Oh yeah let's just drop the e-commerce market that's been built up around the internet and been an economic boon and go back to the dark ages. How about let's make electronic purchases better? Or better yet how about companies hire better people and/or train the people to follow best security practices?
We'll make great pets