Why we shouldn’t use sequential booking references

I travel a lot with work. In the last 6 months there have only be 2 weeks where I haven’t been to Heathrow airport.

Heathrow isn’t the easiest journey by public transport for me as the PTP HQ is in a field in north Bucks. Hence, I usually end driving to the airport.

I’ve been to Heathrow twice this week, so I booked parking for both trips a few hours apart. That’s when I noticed the booking references were remarkably similar.

The reference is 6 characters, with the charset A-Z uppercase plus 0-9. I don’t think the letters ‘I’ and ‘O’ are part of the charset, but I can’t be certain.

e.g. JFFNM5

The keyspace is reduced further, as the first 5 chars are letters, only the last is a number.

Having booked a few hours apart, then looked back through all my previous bookings, it was very clear to me that the booking references were sequential:

e.g.

UDQSH2 in April

UEZFZ1 in May

UFGZN0 in June

The two I booked most recently were about 15 hours and 3030 sequential references apart. That’s very roughly 200 bookings per hour. Obviously there would be a greater rate at peak times.

200 car park bookings/hour seems reasonable for an airport with >10,000 parking spaces and >200,000 passengers per day

But what could I do with this?

Someone malicious couldn’t alter my booking without my email address. Good.

That got me thinking: Don’t start with the booking reference, start with the victim

If I knew who my victim was and roughly when they made their parking booking, I would likely know their email address and could simply brute force the booking reference.

It would be easy to predict the rough booking reference range by extrapolating from a known reference booking and adding the rough 200 bookings/hour stat.

I can’t see that Heathrow Parking have brute force protection, as it would be too easy for a malicious actor to lock out valid users through bruting. I haven’t tried, as that wouldn’t be ethical.

Once I’m in to the booking, what can I do?

The usual information disclosure stuff: name, address, email address, car registration etc.

However, one can also amend the booking:

Want to cancel it?

That is going to really annoy the driver when they rock up to the ANPR gates. No booking. Pay premium prices for unbooked parking (if there are any spaces left) and probably pay a cancellation charge

Want to extend it a LOT?

You’re going to get a BIG bill!

From a previous amendment I created intentionally, the original credit card I used was billed without further authentication…

So what?

I don’t understand why Heathrow parking chose to use sequential booking references. It would be trivial to generate a random reference that would completely avoid this problem.

Most web apps moved on from sequential session IDs years ago for this very reason – account compromise was simply too easy.

The consequence of this ‘attack’ is likely simply to annoy drivers parking at the airport.

Can you see the difficult conversation with the parking call centre after: “my booking was extended by 20 days without my permission, I want you to credit those charges”

“No sir, we can’t do that as you amended the booking yourself”

And no, those aren’t my real parking references ?