Another "record locator as password" scandal

The hacker known as “Alex” / @mangopdf has reported yet another incident in the continuing 20-year-old saga of the security and privacy vulnerabilities that result from airlines and computerized reservation systems using a short, simple, system-assigned, unchangeable, insecurely handled “record locator” for each passenger name record (airline reservation for one or more people for one or more flights on one or more airlines) as though it were a password, even though record locators have none of the attributes of secure passwords: “When you browse Instagram and find former Australian Prime Minister Tony Abbott’s passport number”.

It’s Alex’s story, and he tells it much better, and much more entertainingly, than I could. But after you’ve read his account of using the record locator visible in a photo posted by a former Prime Minister (!) of Australia to his public Instagram account to retrieve the ex-PM’s PNR on the Qantas Web site, and then finding the ex-PM’s phone number and diplomatic passport number in the HTML source code for the Qantas PNR-viewer Web page, I have some comments about the back story to this incident:

1. This is not a new vulnerability.
   Airlines and CRSs have used system-assigned, unchangeable, “record locators” for PNR retrieval for decades. The first gateways from the online services (EAAsy Sabre) and then the Internet to PNR databases in the 1990s continued to use the existing record locators. Online check-in and flight-change systems continued this pattern, expanding the potential damage from exploits of this vulnerability.
   
   
2. This is not a previously-unknown vulnerability.
   I reported this vulnerability to Amadeus, Sabre, Galileo, and Worldspan (the last two now both part of Travelport) in 2000 and 2001. When they did nothing to fix the problem, I wrote about it in my book “The Practical Nomad Guide to the Online Travel Marketplace” in 2001, and in an article in my e-mail newsletter in 2002. Since then, there have been periodic public exploits and reports of this vulnerability:
   • 2006 — The Guardian
   • 2016 — Live public demonstration at 33C3 hacker conference
   • 2017 — BBC interview
   • 2019 — Techcrunch
     
     
3. This vulnerability could be fixed.
   It’s tempting to think that because PNRs are stored in “legacy” systems, it would be impossible to secure them. But it would be possible to require passwords for access to PNRs. It would take work, but it could be done — and it would take less time and cost less than the several billion dollars that have been spent since 11 September 2001 to modify airline IT systems to accommodate government surveillance and control of air travellers. Actual customer safety and security hasn’t been as much of a priority for airlines or CRSs as government or commercial surveillance or business-process automation.
   
   
4. This vulnerability hasn’t been fixed yet.
   “Alex” says Amadeus and Qantas claim to have “fixed” the problem, but that’s not really true. What they’ve done is to remove passport and phone numbers from the HTML served up when you log in to their check-in or other Web services using a record locator and surname. That doesn’t address the underlying problem that you can still log in with only a record locator and name, without a real password. Retrieving the PNR and flight itinerary is itself a vulnerability, e.g. if the threat is from a stalker or thief who wants to know when and on what flight you are booked to return, so they can ambush you on your return or raid your home while they know you are still away. There are many other ways to exploit a PNR once it is retrieved, even without the traveller’s passport or telephone number. (Airlines and CRS have done a miserable job of modeling or mitigating the real-world threats to travellers that I saw in my work as a travel agent.) A real fix requires real PNR passwords, including for online check-in.
   
   
5. Government agencies have also known about this vulnerability for years — and have also chosen not to do anything about it.
   The following are some of my formal submissions pointing this vulnerability out to U.S. and European Union government agencies:
   • 2009 — Comments to the U.S. Federal Trade Commission co-signed by consumer and privacy organizations
   • 2013 — Testimony as an invited expert witness before the Advisory Committee on Aviation Consumer Protection of the U.S. Department of Transportation
   • 2017 — Complaint to the European Commission (This complaint remains pending. The only response to date from the European Commission has been a June 2019 notice contemplating dismissing the complaint without investigation.)
   • 2018 — Comments to the European Commission on the EU code of conduct for CRSs

A common question I’m often asked by people unfamiliar with airline-industry IT is why the industry hasn’t fixed this vulnerability.

There are, I think, two main reasons:

First, airline and CRS systems were, and in some ways still are, ahead of their time. Because for many years they had no real counterpart in any other industry, they operated, and in many ways still operate, in a parallel universe with its own standards and its own culture in which customer privacy has never been a concern. CRSs were designed long before customer privacy or security were design criteria. Inertia rules, in the absence of a financial incentive or regulatory mandate for change. Privacy and security could be “backported” to these legacy systems, but there’s no reason to spend money or risk instability to make a change (these systems must operate worldwide, at scale, in real time, without interruption) unless there’s money to be made from the change, or unless some government authority orders it. I’ve long assumed, pessimistically, that the impetus for change would come only after there is some shocking privacy breach that makes the liability for inaction too obvious for airline and CRS management to continue to disregard, such as a stalker or domestic abuser using access to PNR data to stalk and kill their ex-lover or kidnap their children.

Second, requiring passwords for PNR access would introduce “friction” in the customer/user experience that would slow down passenger flow and impede the adoption of self-service check-in, flight change, cancellation and refund, etc. systems that generate increased profits for airlines by shifting work from airline staff (or contractors) to travellers themselves.

As I explained in my comments to the European Commission in 2018:

Airlines accept this lack of security because it facilitates automation through self-service systems that reduce airline labor costs. More secure systems that require a unique or user-selectable password for access to each PNR would require more airline and/or airport staff to deal with lost or forgotten passwords, and might reduce or slow adoption of self-service check-in, flight change, or other labor-saving systems. In the absence of data protection enforcement, airlines have a financial interest in prioritizing their own business process automation over the security of travellers’ personal data.

Airlines and other CRS users will implement more secure, but more costly, PNR access controls only if they are forced to do so through enforcement of data protection requirements, or if passwords are implemented by CRSs as requirements for all users.

None of the previous “record locator as password” scandals have prompted any real change. It remains to be seen if this one will.