<body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d6566853\x26blogName\x3d1%25+inspiration\x26publishMode\x3dPUBLISH_MODE_BLOGSPOT\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttp://patke.blogspot.com/search\x26blogLocale\x3den\x26v\x3d2\x26homepageUrl\x3dhttp://patke.blogspot.com/\x26vt\x3d8220196945898414734', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>
Archives
Subscribe


Tuesday, August 18, 2009

So some jerk stole 130 million credit cards. That's a lot of credit cards. By some estimates, there are 540 million credit cards in the US.

Which means that for each credit card you own, there is a one in four chance that this guy has the details for that card. If you own 4 credit cards...he most likely has the details of at least one card.

That's freaky. Maybe there is a problem with the credit card concept that could be improved?

...but identity theft is not what I am writing about. My gripe is around data encryption. If you have to store sensitive information in a database - ENCRYPT IT. It's as simple as that. Passwords and credit card details should ALWAYS be stored encrypted.

Permalink
Comments:

 
The theft of all these CC#s doesn't surprise me at all; it was really just a matter of time. In fact, I am only really surprised that it didn't happen bloody sooner. The typical "web" user doesn't realize how vulnerable all those "packets" of data really are. I mean "data sniffers" have been around since the time I was born. I agree that the only viable solution (given that the web is here to stay), is data encryption. 128 bit data encryption is the gold standard that we, as citizens, deserve. When will those tossers in parliament see the light? I understand it is important that these technologies do not fall into the wrong hands, but the general public has the right to protect their own PRIVATE data and keep it out of the hands of the criminal element.

 
But if your database is used automatically by an online Web site that allows using credit cards for purchasing and actually performs purchase initiation (using the credit card numbers), then even if you encrypt the numbers, you will have to keep the decryption key somewhere inside the network, because the Web site would need to access the data.

In this case all you could probably do is physical security AND maximum security on the key server.

Of course, one could hire a person to perform purchase initiations, and therefore to read the credit card number a person is needed (and that person could keep the decryption key on a removable device).

Or, as DlhSoft does, DO not store credit card numbers in the database and use an external, trustful, service for payment, such as 2CheckOut.com or PayPal (2CheckOut.com now supports Paypal itself).

 
Thanks Sorin. You are 100% right - the best security is to not store credit card data at all. I followed the same practice with JetTask back when it was for sale. In fact, I am pretty sure that payment processors like Paypal and 2Checkout don't event send the customers card details. A smart move on their part.

Combining this with Howard's comment: Maybe what is needed is more government regulation? People should be in charge of their own data and how many people want the convenience store at the end of the road to have their credit card details "of file"? The ONLY company I can think of who I am comfortable having my credit card details is PayPal. I think PayPal has a legitimate "convenience" arguement.

Regarding storage of keys - security is an onion. Layers is the key. In this particular case, the hacker got to the data via a SQL injection attack. Even if the key had been stored insecurely, encrypted data would have prevented the issue. ...in this case.

 
BTW, I am not advocating "government regulation", but rather letting the general public (GP) use technologies that have already been developed to protect their data. But I am curious, what SQL "injection" technique did these hacker's use? I've had to battle trojan horses and the never-ending phising attacks when I worked as a sysadmin in the past, but this new one is news to me.

 
>"letting the general public (GP) use technologies that have already been developed"

The trouble is, from a technical perspective, it is not the customers choice. It is the service providers choice.

Let me ask you this: should the head of IT at the offending institution be looking at jail time for not securing the data? ...a fine?

Before you answer, keep in mind that because of this guys incompetence, 130 Million people had their identity stolen. That is a crime far worse then robbing 100 banks.

On the one hand, I say "yes". Absolutely. This guy screwed up and now ordinary people have to pay. On the other hand, I work in IT. :-) ...nothing is ever really secure, so how can you hold someone responsible?

>SQL "injection"

Imagine a web form with a drop down "name, address". This field is used in a SQL query. Select Name from tblUser.

The hacker modifies the drop down to "name, address, creditCard". The query then becomes: Select creditCard from tblUser.

...that's a simplified description. Check out wikipedia.

Post a Comment