Hacker News Reader

Comment by avar | Hacker News Reader

I work for Booking.com (in areas unrelated to this, mainly Git infra these days) and have forwarded this as a bug report to the relevant internal channels.

Some brief digging reveals that the most likely cause is some combination of casting a "000" CVC to a "0" int before a subsequent boolean test (most of this is Perl), or some form validation using PositiveInt etc.

I can't comment on what OP on Stack Exchange was told as an explanation other than to say that I think in general customer support at large organizations is going to have a hard time with the triage of customer issues to determine if they're internal software bugs or not.

I myself have tried reporting probably 10-20 things I 100% knew to be software bugs to various companies through the years, almost never getting through front-line support, and usually finding someone via IRC/Twitter or mailing something like security@.

View on HN

> Some brief digging reveals that the most likely cause is some combination of casting a "000" CVC to a "0" int before a subsequent boolean test (most of this is Perl), or some form validation using PositiveInt etc.

Probably worth noting in the bug report that the problem is not that '000' needs to be special cased here so that a resulting 0 is allowed from the cast in that case, but rather that the cast to an int should not be happening at all.

The CVC code is not a number. It is a 3 or 4 character alphanumeric string all of whose characters are from the set {'0', '1', ..., '9'}. The only validation that should be done on the merchant side is checking the length and checking that all the characters are members of that set.

It's kind of funny. The credit card number is also an alphanumeric string all of whose characters are from that set, but I don't think I've ever seen anyone cast that to an int. I wonder why people make that mistake with the CVC but not with the card number?

Casting a credit card number to an integer won't run into this problem, because the major credit card networks don't use a leading zero in their card numbers (the first digit generally identities the network). Also, credit card numbers may be too large to fit into a default integer, so you're likely to notice if it doesn't work, but you're less likely to have tested with CVCs with leading zeros.

That was obviously the problem. It was the first thing I thought of.

But if one of the answers on SE is to be believed, this bug has uncovered a serious security concern. A person who also claims to work at Booking.com said that they do not charge cards, but pass them onto the booking hotel.

If true, that's incredibly dangerous. Anyone who has gone through PCI-DSS compliance knows that the cardinal rule of CVC codes is that they are never to be stored. They are to be used to charge or pre-auth the card, and immediately discarded.

I think your experience is correct as far as it goes, but many people who've dealt with PCI-DSS have only done so in the context of companies where the delay between pre-authorization and post-authorization is seconds, e.g. some online merchant where you immediately charge the card.

During this period you can store the CVC, and in some industries, such as accommodation, that time can be weeks/months. E.g. standard practice in some hotels is to store this information at check-in and charge on check-out.

This blog two-part blog series is enlightening:

https://pciguru.wordpress.com/2018/01/27/pre-authorization-a... https://pciguru.wordpress.com/2018/02/17/pre-authorization-a...

And here's Booking.com's official documentation for partners showing that they can access the guest's CVC code (once):

https://partnerhelp.booking.com/hc/en-gb/articles/3600007643...

Thanks for that.

It is usual practice to pass on payment details to a hotel rather than the booking agent charging the cards themselves. This can be compatible with PCI-DSS when details are tokenised and stored with a third party.

Reply on news.ycombinator.com