Mysterious leak of Booking.com reservation data is being used to scam customers
arstechnica.com
arstechnica.com
Having worked at an OTA (before Expedia got us) I refuse to book at anything other than a legit hotel system. OTA's are fine for price discovery but you often get a better deal (and better service) from the hotel/brand directly. The front desk knows you booked via an OTA instead of the hotel directly.
One time I had a not so nice experience with a hotel. They promised a partial refund, but also a threat that they'll re-charge my CC the full amount if I wrote a bad review. No such refund came, I wrote a bad review, then they talked to me and did actually refund me. But how could they re-charge my CC without the CC info? I smell a violation of PCI DSS there.
That used to be more true in the past, but recently OTA's are beginning to offer better rewards programs, as well as making your trip more 'interconnected' (having one place to get flight, hotel, cars, events, activities, etc.), so now I'd say "it depends". Lately though, the bigger hotel chains themselves are also starting to introduce their own rewards, so we'll see what happens
The UI of hotels website is also often terrible and I absolutely do not trust them with my credit card info (nor do I wish to send them a SEPA deposit which I have seen at more than one place).
For flights on the other hand I take the airline website any day.
Sometimes identifying “the airline” isn’t straightforward.
Found a great routing+price: Toronto-Philadelphia-Paris on an OTA, all on AA metal.
But the fare wasn’t available on AA.com, you had to find it on Iberian’s website which booked some of the legs through a Finnair codeshare.
So had to book on booking.com and other multinational sites.
I know anecdotes aren't data, but I've had the opposite experience.
Front Desk: "Hey, I see you booked with Expedia. You know if you booked directly with us, you'd get a better rate!"
Me: "Oh really? Thanks! Can I book tomorrow night at the same rate as tonight?"
Front Desk: "No, sorry, tomorrow night's rate is twice as the rate you have from Expedia."
Me: "Ok, I guess I'll book at Expedia for tomorrow night as well, since they have the same rate that's half of what you're offering me."
I've had this happen so many times!
When asked directly, they just tell me to book on Booking.com.
That way Booking.com would be able to see the contents of any messages and shut down spammers more easily. They could do the same with a phone / SMS relay as well.
To put that into perspective, has Amazon managed to reliably detect and shut down compromised Marketplace shops yet?
How come their (optional) 2FA only offers SMS, which is known to be insecure, even though FIDO2/WebAuthn/TOTP has been a thing for years?
The problem is, as always, users. When the EU recently adopted PSD2, banks were forced to implement 2FA for online banking... and there was a ton of backlash. Anything more complex than "enter one-time code from SMS/e-mail" will lead to a lot of customer support issues.
With SMS based 2FA, you as a service provider only have to deal with people who lost/damaged their phones and need access while they get their new phone set up or with 2FA token messages being stuck in spam filters. With anything else, you as a service provider will have a lot more scenarios to cover in support: people unable to set up TOTP apps, people travelling who need access but forgot their Yubikey, an employee took their yubikey home to work from there and fell sick but now no one can log in any more from the office (because the yubikey is with the sick employee), the yubikey got damaged, the computer is in service so no webauthn possible, the users originally had an iPhone compatible Yubikey but now have an Android device or vice versa and now need new keys... and you will have scammers acting like one of the aforementioned scenarios has just happened. Oh, and at least TOTP usually has some sort of backup codes, but people regularly lose the files or, in very random edge cases, a regular TOTP code is the same as a recovery code so the system strikes the recovery code as having been used and people get confused as a result...
The easiest of the bunch is TOTP because the setup code can be backed up, but not all employees want to add corporate credentials on a personal phone, and because it's completely stateless (similar to classic JWT bearer tokens) it's impossible to keep track of the 2FA credentials and who has them, meaning a ton of work when employees depart.
Hell even the really large players don't get 2FA right. The best example is Amazon AWS: as a root account you should have 2FA enabled. But if you want a yubikey, you can only add one, with no fallback for a TOTP device - lose your yubikey and you're at the mercy of AWS support.
Identity and access management is insanely hard.
That, however, doesn't mean booking.com isn't a shitshow in itself. I have an account with them that should have everything saved - my name, address, credit card information and the name of my s/o - and yet, for every booking I place I have to enter all the information from scratch. How they haven't managed to implement that in years is inexcusable.
Sounds like an issue with you or your account. I never have to enter my information and bookings go usually pretty smoothly if you ignore the dozens of dark patterns. I just tried and it takes about 7 taps from list until Pay button (my CC is saved) on my iPhone app. Technically I didn’t even have to scroll.
> as a root account you should have 2FA enabled. But if you want a yubikey, you can only add one, with no fallback for a TOTP device - lose your yubikey and you're at the mercy of AWS support.
As a fallback for my spare Yubikeys, I have created a couple of dummy, web-only IAM users with root privileges.
Still an embarrassing UX failure on AWS’s side though.
Last I checked (and by that I mean found out the hard way) there are still places across AWS that you can lock everyone but root out of. Particularly it seems around a few of the places where you're configuring policies on specific resources rather than through IAM.
We ended up setting a policy on an S3 bucket that locked everyone out. The root account _always_ has permissions to edit/remove that policy, but the policy itself prevented the admin accounts from removing it.
You’re correct, those have the AdministratorAccess policy, not root. It’s been a while since I set those up.
For practical purposes, wouldn’t AdministratorAccess be sufficient to recover from a lost (root user’s) YubiKey?
Same as most other small and medium businesses that don’t specialize in tech.
I think this is even a stretch. They likely don't know the difference between SMS and whatsapp/iMessage, it's all just a "message" or a "text".
After making a lot of fuss, they'll eventually waive the no free cancellation policy, but then I still have to go over the whole process of finding another place to stay.
For Russian speakers there is a joke in there.