I once had a card with 000 CVC. This actually caused me more problems with form validation because 000 can be falsy depending on validation implementation. Sometime I would get a "you must put something in this field" depending on the site.
Fun to read but I don't agree with the accepted answer, which props up the booking.com bullshit. I prefer the answers that highlight the fact this is just a validation bug as that seems most plausible.
I live in the Netherlands and have a MasterCard credit card from ABN AMRO. The pin for this card gets assigned when the card is issued and the only way to change it, according to ABN AMRO, is by requesting a new card.
I can change my PIN through online banking site, just requires SMS password as confirmation. In fact that's how I set initial PIN when activating a new card. Never tried doing that in ATM.
The only thing that would make 000 less secure in this setting would be if the actual CVC codes weren't randomly generated by the bank. Otherwise 000 has as much likelihood to be accepted/rejected than any other codes. Conversely, one could argue that if CVC codes were chosen or could be modified by the owner of the card then disabling the use of 000 could be understandable as lazy users would choose this weak code more often than any other numbers. Also, at the extreme say a merchant starts rejecting all kinds of values, and the attacker knows them, it may also affect its security by narrowing its space of valid values therefore increasing the probability to randomly find the right code.
It's the bias in guessing that matters, not the bias in generation.
If nobody ever guessed 000, or it was guessed exactly 0.1% of the time, it wouldn't be insecure for 90% of people to have a secret number of 000.
At the other extreme, if 90% of people guess 000, then it's insecure to have a secret number of 000, even if it was perfectly randomly generated.
People can learn about biases in generation, and use that to inform their guesses. So biases in generation indirectly matter. But inherent biases in guessing are just as important. Being a perfect RNG is not enough if your keyspace is small.
> A random number in the range 000-999 is more secure than 001-998, rejecting values weakens it.
This sort of argument gets misused a lot. If your entire list of exclusions is less than 5% of the keyspace, you have not meaningfully weakened security. The ability to detect when a number has been left at its default value is far more useful.
It's probably not worth excluding real customers to get that "is the number default?" check. But as a critique on the design of CVV, the system would be better if it never assigned 000.
The comment you replied to didn't include that condition, and I'd be reluctant to state some arbitrary percentage – as you conjure up 5% – to be 'meaningful'. A larger keyspace is strictly more secure against an attacker trying to guess the key.
It's absolutely ridiculous to worry about the security difference between 9.966 bits of entropy vs. 9.964 bits of entropy.
You are also assuming the attacker is optimal. If the attacker has a bias that will reliably exist, and you counter-bias your generator, you can get better than 999/1000 odds against the average attacker.
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@.
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.
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.
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.
> 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.
I work with somewhat dated MX credit card processing terminals at times, tied to Chase. When manually entering a card number for a correction (such as refund for a double charge ) or adjusting a charge, 000 works just fine as running it manually without the chip aspect doesn’t really need the correct Code.
Not really related, but, most merchants can process payment with or without the code. It really just becomes a compliance issue.
One reason might be to validate that the card works at all.
Another might be to bypass anti-fraud provisions of the issuer. (It seems plausible that someone trying to buy a laptop at a random retailer away from home might be less likely to trigger a fraud alert if they had a same city, same timeframe hotel reservation on the card.)
As discussed elsewhere in these comments the booking agent will likely not be processing the payment and probably won't perform validation of the details save for a Luhn check on the number.
We've encountered this before at work. It wasn't an issue when we rolled our own credit card processing. But when we switched to a popular payment service, we found out that "000" isn't a valid security code. There was no way to get around it. They made the customer get a new card from the bank. It was a very fun conversation to have.
I stopped using booking.com after I booked a hotel for the wrong dates, and they made it really difficult to cancel, and charged the entire price of the stay. Now I use aggregators to figure out where to stay and then book directly with the hotel.
They're using in-band signaling. This speaks to poor implementation and decisions on it. There are a lot of other simple numbers that could've been used for invalid. -1 comes to mind.
I once had a credit card with the CVC code of 007. Although it looks cool and everything, I spent a few hours on the phone to manage to activate it.
Why?
Simply because only a few days prior to the arrival of my card, the bank switched to voice-command-only menus on their hotline without a regular menu fallback.
I remember looking at the back of the card and saying, “oh, here we go...” to myself. Unsurprisingly, telling the system “zero-zero-seven”, “double-zero, seven” or even pausing and yelling “SEVEN!” did not work.
In the end, I made the system connect me to a random human-being who then transferred me to someone else and that person redirected me to the regular, typing-based interface.
A few weeks later, they updated their system to fall back to the old system after the 5th error ¯\_(ツ)_/¯
35 comments
[ 3.5 ms ] story [ 66.4 ms ] threadIf nobody ever guessed 000, or it was guessed exactly 0.1% of the time, it wouldn't be insecure for 90% of people to have a secret number of 000.
At the other extreme, if 90% of people guess 000, then it's insecure to have a secret number of 000, even if it was perfectly randomly generated.
People can learn about biases in generation, and use that to inform their guesses. So biases in generation indirectly matter. But inherent biases in guessing are just as important. Being a perfect RNG is not enough if your keyspace is small.
This sort of argument gets misused a lot. If your entire list of exclusions is less than 5% of the keyspace, you have not meaningfully weakened security. The ability to detect when a number has been left at its default value is far more useful.
It's probably not worth excluding real customers to get that "is the number default?" check. But as a critique on the design of CVV, the system would be better if it never assigned 000.
The comment you replied to didn't include that condition, and I'd be reluctant to state some arbitrary percentage – as you conjure up 5% – to be 'meaningful'. A larger keyspace is strictly more secure against an attacker trying to guess the key.
You are also assuming the attacker is optimal. If the attacker has a bias that will reliably exist, and you counter-bias your generator, you can get better than 999/1000 odds against the average attacker.
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@.
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.
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...
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?
Not really related, but, most merchants can process payment with or without the code. It really just becomes a compliance issue.
Another might be to bypass anti-fraud provisions of the issuer. (It seems plausible that someone trying to buy a laptop at a random retailer away from home might be less likely to trigger a fraud alert if they had a same city, same timeframe hotel reservation on the card.)
A fraudster doesn't care who that is, any more than I care who it is when I legitimately book a hotel room.
Why?
Simply because only a few days prior to the arrival of my card, the bank switched to voice-command-only menus on their hotline without a regular menu fallback.
I remember looking at the back of the card and saying, “oh, here we go...” to myself. Unsurprisingly, telling the system “zero-zero-seven”, “double-zero, seven” or even pausing and yelling “SEVEN!” did not work.
In the end, I made the system connect me to a random human-being who then transferred me to someone else and that person redirected me to the regular, typing-based interface.
A few weeks later, they updated their system to fall back to the old system after the 5th error ¯\_(ツ)_/¯