News: 1589891553

Incompetent data controllers often claim to be victims of "highly sophisticated" attacks, despite taking security "extremely seriously".

An unkind person might suggest that many don't think much about whether a database is private / don't check incoming messages against buffer sizes / never heard of SQL injection. To them, I suppose, any attack is "highly sophisticated".

Not to mention apologising for their "robust security measures,"

I can even schpell it when I'm shober!

A 'highly sophisticated' attack in their parlance would be something like:

for ((i=0; i<=9999999; i++)); do wget https://easyjet.com/customerPortal/creditCardDetails?customerId=$i; done

I suspect the people who "hacked" them were not quite up to the sophistication of using a loop - they probably still did it manually.

Or in Basic.

Yeah, that's my normal thinking. "Sophisticated" is code word for "they were smarter than we were". Doesn't say at an absolute level how smart either side was... It's spin from the corporate types to avoid making themselves look incompetent.

It's spin from the corporate types to avoid making themselves think they look incompetent.

FTFY

To the rest of us things look a bit different.

They went further and didn't claim the attack was sophisticated just that the attacker was sophisticated. That is quite some claim - do they know the attacker?

The fact that they "have now closed off the unauthorised source" makes is sound like it is totally not sophisticated at all. Either they've closed off a backdoor, a bug etc or they've removed access to a previous employee. None of which is that sophisticated.

Wasn't the TalkTalk attack originally 'highly-sophisticated' - before it was revealed it was some script kiddies playing with freely-available tools on an unsecured Tiscali database?

Still, it's not like the then-management of TalkTalk are doing anything vital these days are they?

https://www.gov.uk/government/news/new-chair-of-coronavirus-test-and-trace-programme-appointed

This is why it is never a good idea to store your card details on any website. Never have done, never will.

Also, in unrelated news, the website password is limited to only 20 characters .

I hate max characters in passwords, it bloody annoying pasting in from my password manager of choice to be told the password can't be used!

Even worse when the "clever" website programmers prevent pasting into fields.

Or the even stupider ones who use a different set of rules for registration than they do for logging in.

It's even more annoying when your password manager's formula falls foul of a site's rules (e.g. no non-alphabetic characters etc.) that they couldn't be arsed to tell you about beforehand.

My work credit card supplier has a limit of nine with only letters and numbers allowed... It's also the card with the highest credit limit that I have.

And that "max 20 chars password" must not contain "special symbols" such as "&" or "*" !!?!!

Just logged in to change my password but can't see where (or if) any Credit Card info is associated with the account

"...it is never a good idea to store your card details on any website"

Doesn't make any difference. Either these details were slurped in real-time by a script on the transaction page or they were read from the database. Regardless of whether you "store your card details" on a website or not. They will be recorded as part of the transaction unless they are using a third party provider's system (which can also cause issues). Therefore they either need to two-way encrypt the card details and never store the CCV or never store the card details after the transaction has completed and then not have an easy way to securely do refunds. As a punter you won't know what they do with your card details after you have entered them and clicked submit.

For refunds the common sense approach would be to only store the last 4 digits and get the customer to confirm the rest when processing the refund.

Doesn't make any difference.

I'm pretty sure you are correct for actual purchases. I'm unsure how the vendor could handle a chargeback or refund without having the CC number stashed with the transaction data. Likewise monthly subscriptions for services. The alternative to a stored CC for those would appear to be direct charges to your bank account. Somehow, that sounds even worse to me.

But I think the OP was referring to vendors like Amazon who allow one to use a stored credit card number so one doesn't have to type it in every time they order a box of chocolates.

I kind of wonder if it isn't about time for governments to start working on a set of explicit worldwide standards and conventions for digital commerce. Of course there might be a problem if it turns out that no set of standards and conventions that actually allows commerce and is also secure is possible.

"As a punter you won't know what they do with your card details after you have entered them and clicked submit."

Perhaps it's time sites were legally obliged to tell punters what they do.

This is why it is never a good idea to store your card details on any website. Never have done, never will.

They're welcome to my vcard ones - the details change after every transaction :).

The only issue is is that it has become such a habit that I forget it's not very useful for subscriptions. Sorry, Akeeba :).

I wonder just how many times the NCSC face-palms when they learn the details of what "a highly sophisticated source" did to get the data.

And just how necessary is it to store credit card data anyway? I know /we/ don't and we do take such payments.

Its now May. What gives?

>What gives?

Lazy security. It's the gift that keeps on giving.

You will find that it is not be that the Security Team being "lazy",

What you will find that the Management has chosen not to implement certain Security controls in for "Business Reasons" even though the Security Team has demanded it.

You will find that the Business will have a high turnover of Security Team as people join, try and do their best to secure the Business, then realise that the Management are not on board.

What gives? A big fine I should hope. Either that or 72 hours has a different meaning at Easyjet.

Really Il Reg?

If it was funny, I wouldn't mind..... but its neither accurate or funny ..... so do please try again?

Its headquarters, are in the Netherlands, the three largest countries involved are France, Spain and Germany, followed by UK and many other European countries ..... so maybe try something like "Euro-Bloc Flying Fortress" etc ......?

There, that wasn't so hard now was it? ;-)

"As soon as we became aware of the attack, we took immediate steps to respond to and manage the incident and engaged leading forensic experts to investigate the issue."

I'm amazed they responded like this - must have taken some serious thinking to plan for.

"We took immediate steps to respond"

Yup, we sent out some emails and also contacted people than can do nothing.

"manage the incident "

In other words we did our best to avoid GDPR fines.

What we did NOT do was secure our data in the first place... and once the data is gone, it's gone, and soon to be for sale on the Dark Web....

"In other words we did our best to avoid GDPR fines."

Their best might not be good enough if they became aware in January and only notified credit car holders in April.

I just logged on to change my password, I've not had an email saying I my details were part of the leak but it seems like something I should do.

No sign of any information about this on their website yet or even an automatic prompt to change my password.

Sheesh, here we go again, another big name scrimping on IT security and using Stevie Wonder for their PCI-DSS audits.

Sod the ICO/GDPR fines, the banks should just take away their ability to take card payments, its not like this stuff is actually difficult.

If it's SQL injection again they really need to rethink their application and DB tiering, but I'll hazard a guess that everything is running on a single Internet-facing tier.

I'd call them cowboys, but at least cowboys wear boots.

Who here allows credit card details to be stored server-side, "for future purchases"?

Done properly storing credit card details isn't a problem since the actual details themselves are never stored just a reference token that can only be used by that one merchant. Of course as an end user you have no idea if the website is going to do it properly or just chuck them into a table next to your email address and password.

As mentioned in the article this most likely isn't Easyjet storing card details but some kind of script running on top of the website harvesting the card details as they are entered. It makes little sense that Easyjet would have card details stored in an accessible way for 2200 people only.

Right now I'm coding the card-taking bit of a site I'm developing and no bloody way, my non-technical business partner wanted us to handle it all in-house to reduce transaction costs but I refused to. No way I'm being responsible for that sort of stuff.

We're using a proper/expensive card processing company, storing nothing card-related for one-off payments and only storing a token to re-identify customers for repeat subscription charges, and I'm being super-paranoid about that, Azure Key Vault for the db connection string and authentication key for the card processor, proofs against sql injection of course, custom obfuscation of the tokens and key itself (because why not), super-locked down privileges about which users can initiate financial stuff (not the ones used by interactive sessions for a start, not even admin users!) and I'm still looking around to see what else I can do.

The idea of leaking people's names and emails is scary enough, even for our small user-base, but card data; jeez, that's terrifying.

Kudos to you, sir - - - - >

Nice to see that there are web developers that have a sense of propriety, scope and sensibility. If only you weren't in the minority...

The main website uses tokenisation of Credit Card details.

If it wasn't then all customers details would have gone, this is most likely some 3rd party site which provides a service to EasyJet. Although it is still EasyJet who is responsible.

I predict the ICO will announce with great fanfare that they've fined EasyJet hundreds of millions of pounds.

Then, years later, you'll find they repeatedly deferred enforcement, eventually settling for 5000 in 2027.

Easyjet would probably [1]only offer them vouchers anyway...

[1] https://www.easyjet.com/en/refund-form

"The Information Commissioner’s Office said in a prepared statement that it has “a live investigation into the cyber attack involving easyJet” but did not answer questions about when Easyjet notified it of the hack. The agency has previously said it will not be enforcing data protection or freedom of information laws during the coronavirus pandemic, something noticed by Wired magazine today."

Wait, what?!?

The agency has previously said it will not be enforcing data protection or freedom of information laws during the coronavirus pandemic

WTF!

So it is earier getting data and creadit card details from EasyJet than getting a refund on a cancelled flight!

Was due to go to Krakow in March but as Poland shut the airport EasyJet cancelled the flights. Got a refund for the flight out - but the flight back has been deleted from my bookings making the task of applying for a refund a tad difficult. Trying the creditcard route but they are similarly in being un-cooperative.

The PCI DSS security standard for handling credit cards mandates this. If easyJet (subs note sp) were doing so (about as unlikely as storing their site password in clear text), they'll be in a world of trouble. The standard also requires all CC data to be strongly encrypted.

The PCI DSS security standard for handling credit cards mandates this. If easyJet (subs note sp) were doing so (about as unlikely as storing their site password in clear text), they'll be in a world of trouble. The standard also requires all CC data to be strongly encrypted.

Flaws in encryption are almost always around key management. Encrypting a block of data is just a library function call, but key management is a tricky design problem fraught with potential difficulties.