Someone didn't steal my identity, someone stole from the bank using my identity. It should really be called "bank fraud".
Of course, this news doesn't help them now, but it doesn't seem to me like "poor old EasyJet, down on their luck and now this".
The summary is: fraudster with fake ID featuring real data of my friend but fake photo managed to get loans and credit cards from several banks/companies. Since my friend lef the country, he was not getting any of the post. After years these orgs opened collection cases against my friend. Since he was not in the country, the courts have judged him as debt-evader and allowed collection agency to act against him.
It needs to be so expensive to store extensive data of millions of people that companies (or for that matter, the government) cannot wait to get rid of it.
Currently, most online shops nudge me towards opening an account and letting them store my data indefinitely (to facility marketing and reduce friction). They should do the opposite, nudge me towards not causing them the hassle of storing my data beyond the immediate business transaction.
Having said that, I also think a large part of the problem is that treating data like toxic waste is hard. There are more established patterns for data collection than data destruction. How do you know when it’s safe to delete some piece of data? What if the user comes back and complains about a transaction after you’ve deleted the associated data?
Imagine EasyJet putting the burden of keeping all your transaction logs on you: "Passenger assumes responsibility of downloading this electronically signed package and keep it for 2 years"
On a completely tangential note: How does your product work with pets?
I agree, but this is exactly analogous to the SDLC. Most coders only learn to hack together barely-working code. Those who spend the effort to learn the craft figure out how to {version control, unit test, static analysis, benchmark, integration test, upgrade library dependencies} and automate these processes.
Similarly, there needs to be a data lifecycle with defined retention lifetimes for different data, defined processes for actually disposing of data, and special handling cases for backup blobs (which may be retained longer than the retention lifetime of a subset of the data in the backups). This is effectively intended by the GDPR (not sure if it states explicitly) and similar laws.
> I also think a large part of the problem is that treating data like toxic waste is hard.
Yep. It's a -lot- of extra work to do. It's a balancing act between:
- Keeping data long enough to satisfy govt regulations, rulings, or existing contracts with your vendors (i.e. merchant account with a bank for CC processing.) You can't just order something from amazon, Send a GDPR request and expect all your data to be gone; They can't delete it until -after- those retention periods have expired.
- Following Regulations like GDPR/Cali Privacy law.
- Still doing meaningful things with the data.
Generally speaking, I'd say this is all stuff that makes a Data architect very handy in the modern climate.
Doesn't PCI require a payment processor to keep some amount of the transaction data for a specific period of time?
Personally, I love tokenized transactions / specialized payment processors (eg Apple Pay, Stripe, PayPal) because they actively work to keep most of the data away from etailers (who are generally not specialists in securing their checkout flow). The problem is the payment processor transaction fees can be steep (2.x% for most commodity CC processors all the way up to 15% for Apple Pay), so etailers lose on the margins and avoid the more secure options.
Certainly in my own business, I want as little PII as possible.
Just wanted to give this info as a sort of reference. I remember when I first found out how they worked that I was so shocked that it wasn’t more of public knowledge
Typical. When are we going to get tired of the same PR, damage-controlling, bullshit that we all know are blatant lies?
EDIT: we need a GDPR hero.
> Your password must be a single word between 6 and 20 characters in length and must not include the special characters # & + or space.
Come on! This is ridiculous. If you're going to get hacked at least have a sane password policy.
Am I missing something here? This doesn't make sense really.
[0] https://news.ycombinator.com/item?id=23233619
[1] https://www.theguardian.com/business/2020/may/19/easyjet-cyb...
I also removed my credit card at some point after this from every single website - and changed the card in real life. So even if there is a card number somewhere in a db, it's not valid anymore.
I'm tech savvy and this still took around a day, and it was a pain in the ass but hopefully mitigates some of the fallout from this hack - but to be statistically safe while continuing to use online services, id have to wipe my passwords and cards every few months given the frequency of hacks. I couldn't expect my family to put this much effort into doing this frequently.
The system of holding a central database is completely bust. It's just too juicy a target to keep the hackers at bay.
I really wish there was more effort today spent on changing this centralised paradigm to a decentralised one - my personal data should live on my computer, and my computer only. It should never ever leave it. It should always be hashed.
If there was some way for web apps to be distributed and ran on my own personal computer, with zero knowledge proofs verifying transaction on the third party services side we would seriously reduce the attractiveness of hackers going off these enormous databases. It needs to be as easy to secure this data as possible, and it needs to never be sucked up to somewhere else, and security patches need to be instantly applied over the top of my running kernel - without any hiccup.
Impossibly difficult you will scoff. No one wants to run their own software. They absolutely would if the tech industry put any effort into it. Also the fines need increased massively to incentivise action in this direction. It should be business-ruining if you lose your customers data like this.
When such details are omitted I tend to suspect that "highly sophisticated" is sugarcoating some kind of negligence or bad security practices.
Getting compensated should be practically instant though, and definitely not take a year, so something went terribly wrong there.
I always found it interesting how they have much better tea than British Airways.
Generally you are right yes, it is airport service under one of the operating company of the airport.
However easyJet and other low cost airline have generally a very vertically integrated system where they try to operate almost everything themselves to reduce cost.
Some airport have entire dedicated terminal for them, I would not surprise if they manage also their luggage system in these airports.
vs
> The GDPR introduces a duty on all organisations to report certain types of personal data breach to the relevant supervisory authority. You must do this within 72 hours of becoming aware of the breach, where feasible.
So either EasyJet was delayed in their reporting of the breach, or the ICO didn't feel it was urgent to notify 9 million people that their data had been compromised. But it is now 4 months later?
> we took immediate steps to respond to and manage the incident and engaged leading forensic experts to investigate the issue. We also notified the National Cyber Security Centre and the ICO. We have closed off this unauthorised access.
Maybe the relevant supervising authority didn't find it important to notify those 9 million customers.
Which is a problem right? Now it emerges what has been breached. Including credit card data. Surely the prudent thing would have been to warn all their customers immediately to allow them to be on the lookout for malicious use of their data (phishing, etc.) and not wait until they have concluded their investigation.
(edit)Ah no, no mention of passwords being stolen, so I guess it's from somewhere else.
Bull. Shit!
"Other than as referenced in the following paragraph, passport details and credit card details of these customers were not accessed"
The following paragraph says 2208 credit cards details were stolen.
I don't trust your security.
I wouldn't be surprised if they stored it anyway though
Who the hell makes ‘boarding time’ the same as ‘airplane leaves gate’ time :S
I always thought that PCI-DSS standards mandate that the CVV must never be stored; I get that card number and expiry date may be stored for customer convenience purposes, speeding checkout when returning for a second purchase, but how on earth could they be compliant if they are stashing away CVVs somewhere?
I managed to sign in without a problem :/
I thought GDPR required companies to disclose breaches within a few days. What happened there?!
Guess?
Oh look, EasyJet huh? I wonder what's in there?
A limit always exists. If you don't enforce it yourself you will find out when someone decides to send you 64GB of data to hash as their password. So always better enforce the limit yourself.
These specific limitations indicate that it's more likely to be something bad however, it's funny because I remember adding EasyJet to https://github.com/dumb-password-rules/dumb-password-rules/p... last year.
Given the disallowed chars that's suggestive that the form used to be implemented as a GET, so it's possible passwords were in log files for a long time.
This annoys me the most, my password contains some of those characters.
Why is this even a restriction or is just poorly developed code?
Not only did their system have me logged in another flight in another continent (!), they flat out denied I had a claim even though I had to stay put more than 24h, a good amount of that in the plane.
After getting sued, they tried to backhand contact me (not my lawyer) to pay compensation. Court made them pay.
This is all calculated.
Not really.
Even if you're legally entitled to compensation Easy Jet is famous to let you jump through so many hoops, lie to you, hang you out to dry, let you wait forever until you just give up.
Outsourcing to some company like Airhelp (which, charges 35% of recovered compensation if successful) may be a viable option to just save you the headache, while sticking it to the carrier trying to stiff you.
Fun fact: PHP used to escape some characters in some POSTed data by default before a specific version, then changed the default config:
> Prior to PHP 5.4.0, the PHP directive magic_quotes_gpc was on by default and it essentially ran addslashes() on all GET, POST and COOKIE data.[1]
I know for a fact some of users of a previous site I worked on had stored their password (hash) with one escaping mechanism, only to start failing authentication after that function was no longer used upon data input (all escaping should be done upon output for more perfect control of different security contexts eg. escaped HTML versus escaped SQL versus escaped JSON).
Regarding pets: it'll depend on the size of your pet. For most people, the sensors properly ignore pets, but they can be confused by large dogs. You can adjust the sensitivity of the sensor, so it's generally only an issue if you have both large dogs and small children, and only want to count one of them. We're working on a software update that should help that scenario too. Feel free to send me more questions at neil@hiome.com :)
Banks check during the KYC process whether the document ID is on this blacklist. If yes, authorities are contacted.
Hence, once compromised/lost, apply for a new one and tell them what happened with your old one.
If special chars can be a signal for keyloggers, so are strings > 10 chars, and strings which are not all-lowercase/all-uppercase/first-capital. Basically to mislead the keylogger in this way, the user would have to use a short all-lowercase dictionary password :)
They shouldn't get exposed of course, but they do. [EDIT: redacted an example of some random dude's access log]
If you search for "password" in there you will likely see a new Mirai bot variant [1] bouncing credentials off the server looking for weblogin.cgi on vulnerable Zyxel devices.
I imagine PA highlit this detail in their post ("weblogin.cgi accepts both HTTP GET and POST") exactly to ensure sure defenders don't restrict themselves to blocking or investigating only the more normal POST mechanism.
[1] https://unit42.paloaltonetworks.com/new-mirai-variant-mukash...
I'm not sure when easyJet first started using online accounts, but "you can't use some URI query reserved chars" does seem like a strong indicator there used to be a GET involved.
Early versions of some PHP sites, for example, would pass around auth tokens (think the auth cookie) in a URL. This soon became an obvious problem when users copy-pasted their URLs into forum posts, non-HTTPS URLs were logged by proxies, and web server access logs became gold mines for maybe-still-active sessions.
So, a spy watching your https traffic knows that you're interacting with news.ycombinator.com (and possibly other things), but they don't know anything that goes after the `/`: which thread, whether you're POSTing or GETting, or of course any of the content.