Keeping guests' mobile numbers out of hotel systems

For ViaLuxury we built a verification line. When a hotel receives a booking, it gets a ViaLuxury phone number (an Amsterdam 020 number) instead of the guest's mobile number. If the hotel needs to reach the guest, it calls that number and first gives details it already has for the guest, such as the booking number and postcode. Only then does it get the guest's number.

That way the guest's mobile number does not end up in every hotel's systems by default, so it cannot leak from there either. My advice is to give a supplier personal data only at the moment they actually need it.

Where guests' phone numbers leak

A booking platform passes guest details to the hotel with every booking. From then on they sit in the hotel's system, visible to anyone with an account at that hotel. How well those accounts are protected is up to the hotel. As a platform, you have no control over that.

A fine the Dutch Data Protection Authority gave Booking.com in 2021 shows how this goes wrong. In December 2018, criminals phoned staff at 40 hotels in the United Arab Emirates and talked them into revealing the login details for their accounts in a Booking.com system. With those accounts they reached the data of 4,109 guests: names, addresses, phone numbers and booking details. They then posed as hotel or Booking.com staff by email and phone and tried to take money from guests. (The €475,000 fine was for reporting the breach too late.)

The regulator pointed out that such a message is convincing when the fraudster knows exactly when you booked which room. That takes no card number. A name, contact details and the booking are enough.

It can be much bigger. An attacker was inside the systems of the hotel chain Starwood from July 2014. Marriott bought Starwood in 2016, did not detect the attack until September 2018 and estimated that 339 million guest records were affected. The guest profile table held names, addresses, phone numbers and email addresses, among other things. That is in the penalty notice from the UK regulator, the ICO.

And hotels are a target. In March 2025 Microsoft described a phishing campaign aimed at staff of hotels that work with Booking.com, running since December 2024. The emails were about things like a negative review or a question from a guest. Staff who fell for it installed malware that steals login details and financial data.

What we built for ViaLuxury

ViaLuxury is an online travel agency: guests book a hotel through ViaLuxury, and ViaLuxury passes the booking on to the hotel. We rebuilt ViaLuxury's platform, and the verification line is now part of it.

The booking the hotel receives shows a ViaLuxury number for the guest. When the hotel calls it, the line first asks for a combination of the guest's details, such as the booking number and postcode. If they match, the hotel gets the guest's number for that booking.

The idea is that a hotel only gets the number of a guest it already knows. The hotel has the booking number and postcode anyway, so for the hotel it is one extra phone call. Anyone without those details does not get the number.

What it gets you

If a hotel leaks, its records for ViaLuxury guests hold the ViaLuxury number and not their mobile number. A fraudster with a stolen booking list cannot simply call or message the guest.

Someone who has stolen a hotel's bookings could in principle answer the questions. But they would have to call the verification line for each booking. A leaked list of 4,109 phone numbers is usable in one go. Through the verification line, every number costs a phone call, and every call reaches ViaLuxury.

The guest's number is still stored at ViaLuxury. That is one system to secure well, rather than the systems of every hotel where a guest stays.

What to watch when you build one

The booking number must not be guessable. With sequential numbers, someone who knows one booking can try the next. Use long, random booking numbers instead.

Limit attempts per booking and per caller, and log every lookup: which hotel, which booking, when. If someone requests numbers for bookings at ten different hotels in one day, you want to see it. Attempt limits and logging attacks also appear in the OWASP Top 10 that Erik wrote about.

I would also only release the number around the stay. A hotel needs it in the days before arrival and during the stay, and no longer a month after checkout.

Tell hotels in advance how it works. Otherwise the front desk sees an unfamiliar number and does not know it can reach the guest through it.

Beyond travel

The same pattern fits any company that shares customer details with suppliers, such as an online shop with a delivery service or an installer working with subcontractors. With MOVEit, organisations lost data through a supplier. I wrote about that in lessons from well-known hacks.

The GDPR points the same way. The Dutch Data Protection Authority describes data minimisation as "as few as possible": an organisation may not process more personal data than it needs for its purpose. Providing data to another organisation counts as processing too.

My advice is to check, for every piece of data you share with a supplier, whether they need it always or only sometimes. If the answer is sometimes, it can sit behind a verification step, as it does at ViaLuxury.

Sources

• Dutch Data Protection Authority: Booking.com fined for delay in reporting data breach
• ICO: Penalty notice Marriott International Inc, 30 October 2020 (PDF)
• Microsoft Threat Intelligence: Phishing campaign impersonates Booking.com, delivers a suite of credential-stealing malware
• Dutch Data Protection Authority: The GDPR in brief