Did British Airways accidentally break its own security?

A PhD student from the Information Security Research Group of the Department of Computer Science at University College London, he knows more about internet security than your Average Joe.

Mustafa's been raising the alarm about BA's security for months. In July, he was attempting to check in online for his flight when he kept hitting a roadblock that wouldn't allow him to complete the process. Eventually, he figured out why.

BA only lets you check in online after you disable your ad blocker, "so that they can leak your booking details to tons of third-party advertisers and trackers, including Twitter, LinkedIn and Google DoubleClick", he tweeted at the time. All those ads you see for the destination you've just booked a flight to? Well, this is one of the many ways they're generated.

Mustafa complained to BA's Twitter handlers, who came back with the least useful piece of advice since Jackie Kennedy said "it's a lovely day, let's take the convertible for the trip to Dallas". Check in at the airport, BA's Twitter team told Mustafa, or clear your history and cookies. As Mustafa pointed out to them: "That's not how it works - third parties will already have my details, even after clearing history."

(By the way this is by no means the worst of the technical howlers committed by BA on social media. As Mustafa himself has highlighted, BA's Twitter account routinely asks customers to send them details such as passport number and expiry date, the last four digits of their payment card, billing address, post code and email address, so that they can investigate tweeted complaints. What the BA account often fails to add is that those details should be sent via DM, not in public replies. Thus you'll find customers compromising their own security by posting public replies to BA with all this sensitive information included. BA is the master of inadvertently phishing its own customers!)

Anyway, back to the story. Mustafa wasn't chuffed with BA's response, so he decided to complain to the Information Commissioner. It's a breach of GDPR to pass his flight details to third-party advertisers without his express permission, Mustafa argued in his letter. The Data Protection Act gives a company a month to sort out any complaint before the Commissioner gets his hands dirty, so Mustafa sent his letter to BA and twiddled his thumbs for a month.

On the 20 August - 30 days later - Mustafa received a reply. It dismissed his claims that the check-in site didn't work with ad blockers and argued that by accepting the terms and conditions of its website, Mustafa had agreed to the processing of his data.

The letter made no admission of guilt or error on BA's behalf, but sometimes actions speak louder than carefully worded legal responses from BA's data protection officer, the marvellously named Jonathan Stiff. Because when Mustafa went back to check if BA was still using the offending advertising scripts on its website, they had mysteriously disappeared.

Fast forward a couple of weeks and Mr Stiff now needs a stiff drink. BA has put its hands up to an enormous data breach, where hackers somehow managed to get hold of almost 400,000 transactions, including everything right down to the three-digit security (CVV) code on the back of the card.

It's unlikely hackers would be able to fish such information out of BA's database, and BA's statement suggests it wasn't a database hack. The stolen details were taken during a very precise window: between 10.58pm on 21 August and 9.45pm on 5 September. As the CVV numbers were stolen, it suggests there was a rogue script running on the site.

"They [BA] changed their website to quietly remove the tracking scripts that were leaking booking reference information, although they didn't mention they did that in their response to me," Mustafa told after the hack was exposed. "The day after they replied to the complaint, they got hacked."

In its haste to remove potentially GDPR-breaching scripts from its website, is it possible that BA introduced a compromised script that was responsible for the attack? By rushing to fix one problem, had the company accidentally created a much bigger one?