Over 70,000 unencrypted credit card and CCV numbers stolen

It's apparently been a bad month for security. Adobe had a breach, leaking information about nearly three million accounts. Unfortunately, those reports turned out to be conservative with the actual impact reaching 150 million. Microsoft also had a major IE vulnerability that was being actively exploited, but they quickly patched the hole.

Now, according to the Irish Times, the credit card information of over 70,000 people has been stolen from a company called (ironically) Loyaltybuild. Not only were the credit card numbers themselves stolen, but the related CCV numbers were as well. To add insult to injury, the data was sitting on the systems in an unencrypted format, meaning whoever took the data can start using it immediately. In addition to the direct credit card data, roughly 1.5 million people had their personal information stolen -- including names, addresses, phone numbers, and email addresses.

Now it's time for the lawyers to get involved. It sounds like Loyaltybuild was acting as a a data processor for other companies such as SuperValu, but we fully expect the companies to fight in the court room as to who is responsible for paying the penalties from the breach. According to the law, fines of up to €3,000 on summary conviction or up to €100,000 on indictment are possible, although this has never been tested in court.

Source: Irish Times | Credit card image courtesy of Shutterstock

Report a problem with article
Previous Story

Vine for Windows Phone updated to fix sign-in woes

Next Story

Sony Xperia Z1 Review

36 Comments

Commenting is disabled on this article.

Lingwo said,
Security basics is encrypt important data.

Nowadays to there are many tools to make encryption easy.


The term is "Best Practice"
Encryption is easy as you say, to decrypt the strongest encryption requires a lot of processing power on the other hand.
We did some calculation around some large scale Tesla clusters going for brute force decryption, even there it takes minimum 30 years to crack the code on strong algorithms.
I hope that companies that ignore best security practice rules as the mentioned will get shut down, there is no place in this world for such careless companies.

Not sure why the IE vulnerability was thrown in this story.

This also needs to be corrected...

Microsoft also had a major IE11 vulnerability that was being actively exploited, but they quickly patched the hole.

The vulnerability was NOT in IE11.

If you are going to try to correlate everything bad with regard to security back to Microsoft, at least get your facts correct.

Northgrove said,
Haha, leaked from "Loyaltybuild"? Oh the irony...

"Building loyality by not encrypting credit cards since 1999"


Yeah... A couple weeks ago the exact same thing happened to a Canadian Bank... Ironically called "People's Trust". Everyone's (including my own) phone, address, Date of birth and Social Insurance Numbers were stolen (and unencrypted)... i.e. everything required for identity theft.

Worst part is, they said that users banking info was not stolen. However, if you call and say that you forgot your password, they validate your identity with (GUESS WHAT!!) your date of birth and social insurance number.

FAIL.

darkpuma said,

Yeah... A couple weeks ago the exact same thing happened to a Canadian Bank... Ironically called "People's Trust". Everyone's (including my own) phone, address, Date of birth and Social Insurance Numbers were stolen (and unencrypted)... i.e. everything required for identity theft.

Worst part is, they said that users banking info was not stolen. However, if you call and say that you forgot your password, they validate your identity with (GUESS WHAT!!) your date of birth and social insurance number.

FAIL.

Blame Canada!!

darkpuma said,

Yeah... A couple weeks ago the exact same thing happened to a Canadian Bank... Ironically called "People's Trust". Everyone's (including my own) phone, address, Date of birth and Social Insurance Numbers were stolen (and unencrypted)... i.e. everything required for identity theft.

Worst part is, they said that users banking info was not stolen. However, if you call and say that you forgot your password, they validate your identity with (GUESS WHAT!!) your date of birth and social insurance number.

FAIL.

top lel

yowanvista said,
Why the hell were those numbers not even encrypted in the first place?
Because of the cost of doing so...

-adrian- said,
So how much does it cost to change a system using no encryption to use encryption? it is not a 5 Hour job

This should have been a top priority regardless of any costs. No one should be allowed to leave such things stored insecurely.

Actually no, very few companies would make this a top priority if the cost/benefit analysis didn't work out. It doesn't make business sense to fix something if it costs $10m but the cost of something going wrong may only be $500k... (Extreme example but the point is still there).

-adrian- said,
So how much does it cost to change a system using no encryption to use encryption? it is not a 5 Hour job

Actually, its not much more than that. All you have to do is find your read/write of the numbers and add in then very quick logic and probably add a field or two next to it for last4 and hash if needed. Its not cost benefit, its caring about not being negligent with your customers data.

AH okay. And how does every system storing and processing the creditcard data work with it .. simply read and write numbers, right ? "simply at a field or two" that one is the best part

yowanvista said,
Why the hell were those numbers not even encrypted in the first place?

Because that requires a few lines extra of code and ain't nobody got time for that.

-adrian- said,
AH okay. And how does every system storing and processing the creditcard data work with it .. simply read and write numbers, right ? "simply at a field or two" that one is the best part
You're chatting with someone who deals with encryption and databases on large pci-compliant projects all the time. Two functions, an alter script and changing the way you display the last four. It is incredibly easy. If you have a distributed database, which would be harder, you should have a way of abstracting much of what you do so putting that logic into place is very easy.

Frankly, the hardest part is deciding where to store, how to retrieve, and how to secure your encryption key.

TechieXP said,
Now its going to cost them more. And they may even lose a bunch of clients.

Do it fast and cheap up front and hope it goes well taking the risk it "might" blow up in your face = more profit

Or do it right in the first place and incur more costs

Guess which is chosen in le capitalist mindset?

I know about encryption and how to reach pci compliance. I know that - depending how your system works it could be quite complicated. because just masking the card will not get any part of the system realise which card you are really talking about. adding an additional field could be, depending on the system, be a little bit of a ****ty work. but well.. that's what the software developer is for, right

-adrian- said,
because just masking the card will not get any part of the system realise which card you are really talking about
I have no idea what you are talking about. It's easy for you to know which card you're talking about. Encryption doesn't change relational keys or anything of that nature. Adding another field to any schema is never that big of a deal unless you have red tape for doing so. PCI compliance is a different story, but encrypting the card number and providing the last 4 for display is easy in every single system I've ever been involved with... and that includes retrofitting encryption into systems that didn't have it back in the day. If anything, these days, encryption insanely easy to do and with pci compliance as a guide you have a checklist on how to secure your system.

Edit: Honestly, and I by know means know your skill or where you would sit in the decision making of a system. But it's this attitude that it's hard, taxing, etc. that makes it so systems don't get encryption. The viewpoint is categorically wrong. A web/software/db developer may bitch and moan about it. But except in the most complex of systems it should take no significant amount of time to get done. There is no excuse for building a system w/o it these days just like there is no excuse for not retrofitting it into a system that exists w/o it. Hell, if a system is so complex that it would actually be hard, that system probably needs it more than those that it would be simpler to implement since it is either a larger target or at the very least has a much larger attack surface area. You have to treat your credit card numbers as if anybody can get to them and mitigate that event's impact as much as possible for your customers.

Rudy said,
I was pretty sure the CCV was never supposed to be stored?

Just as CC numbers are not supposed to stored un-encrypted among other things.

SharpGreen said,

Just as CC numbers are not supposed to stored un-encrypted among other things.

That is correct. No storage of CCV and the credit card numbers are supposed to be encrypted IF the company has self certified it self as being PCI-DSS compliant.

If not the banks will pass most of the liability of loss of money back to the company.

(I work for a company that is PCI-DSS compliant)

Zerosignull said,

That is correct. No storage of CCV and the credit card numbers are supposed to be encrypted IF the company has self certified it self as being PCI-DSS compliant.

If not the banks will pass most of the liability of loss of money back to the company.

(I work for a company that is PCI-DSS compliant)

Isn't there also something in the PCI docs about not storing CC numbers on an internet facing server? Or did I just make that up?

fastcat said,
Credit card should not be used for shopping, Bitcoins are much safer.

i think you should just pull your network cable