10 ms·

All zeros in a bank card's CVC code

58 points by ElectronShak 8y ago

alex_young 8y ago
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.
darepublic 8y ago
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.
lazyjones 8y ago
Not to excuse the Booking.com blunder, but I'd return that card for the same reason I once returned one with PIN code "1234" ...
- BillinghamJ 8y ago
  Couldn't you have just changed the PIN?
  - lazyjones 8y ago
    I asked, they couldn't...
    - BillinghamJ 8y ago
      You can just do it yourself at any ATM though?
      - gonzus 8y ago
        Not in EU it seems. Your credit card pin get assigned when the card is issued, and can never be changed after that. Go figure...
        BillinghamJ 8y ago
        That's not the case. EU ATMs have that functionality too.
        gonzus 8y ago
        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.
      - mamon 8y ago
        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.
doe88 8y ago
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.
- Dylan16807 8y ago
  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.
  - doe88 8y ago
    You have a valid point indeed.
Dylan16807 8y ago
> 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.
- Confiks 8y ago
  > meaningfully 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.
  - Dylan16807 8y ago
    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.
- jsnell 8y ago
  Why are you saying 000 is a default value?
avar 8y ago
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@.
- teilo 8y ago
  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.
  - rosbrith 8y ago
    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.
  - avar 8y ago
    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-and-post-authorization-part-1/ https://pciguru.wordpress.com/2018/01/27/pre-authorization-a... https://pciguru.wordpress.com/2018/02/17/pre-authorization-and-post-authorization-part-2/ 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/360000764307 https://partnerhelp.booking.com/hc/en-gb/articles/3600007643...
yial 8y ago
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.
themark 8y ago
Why would someone book a hotel room with a fake card and not show up? Maybe to generate fake expenses ?
- sokoloff 8y ago
  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.)
  - rosbrith 8y ago
    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.
    - sokoloff 8y ago
      Someone will be attempting to process the payment. A fraudster doesn't care who that is, any more than I care who it is when I legitimately book a hotel room.
Wowfunhappy 8y ago
I have an SSN that similarly seems fake despite being real, which has caused issues in the past. <_<
EADGBE 8y ago
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.
jeklj 8y ago
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.
kevin_b_er 8y ago
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.
merty 8y ago
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 ¯\_(ツ)_/¯
- auiya 8y ago
  Ah but this was a British system. You should have said "naught-naught-seven"

58 points by ElectronShak 8y ago

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.

darepublic 8y ago

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.

lazyjones 8y ago

Not to excuse the Booking.com blunder, but I'd return that card for the same reason I once returned one with PIN code "1234" ...

BillinghamJ 8y ago
Couldn't you have just changed the PIN?
- lazyjones 8y ago
  I asked, they couldn't...
  - BillinghamJ 8y ago
    You can just do it yourself at any ATM though?
    - gonzus 8y ago
      Not in EU it seems. Your credit card pin get assigned when the card is issued, and can never be changed after that. Go figure...
      - BillinghamJ 8y ago
        That's not the case. EU ATMs have that functionality too.
        gonzus 8y ago
        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.
    - mamon 8y ago
      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.

doe88 8y ago

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.

Dylan16807 8y ago
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.
- doe88 8y ago
  You have a valid point indeed.

Dylan16807 8y ago

> 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.

Confiks 8y ago
> meaningfully 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.
- Dylan16807 8y ago
  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.
jsnell 8y ago
Why are you saying 000 is a default value?

avar 8y ago

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@.

teilo 8y ago
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.
- rosbrith 8y ago
  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.
- avar 8y ago
  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-and-post-authorization-part-1/ https://pciguru.wordpress.com/2018/01/27/pre-authorization-a... https://pciguru.wordpress.com/2018/02/17/pre-authorization-and-post-authorization-part-2/ 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/360000764307 https://partnerhelp.booking.com/hc/en-gb/articles/3600007643...

yial 8y ago

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.

themark 8y ago

Why would someone book a hotel room with a fake card and not show up? Maybe to generate fake expenses ?

sokoloff 8y ago
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.)
- rosbrith 8y ago
  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.
  - sokoloff 8y ago
    Someone will be attempting to process the payment. A fraudster doesn't care who that is, any more than I care who it is when I legitimately book a hotel room.

Wowfunhappy 8y ago

I have an SSN that similarly seems fake despite being real, which has caused issues in the past. <_<

EADGBE 8y ago

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.

jeklj 8y ago

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.

kevin_b_er 8y ago

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.

merty 8y ago

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 ¯\_(ツ)_/¯

auiya 8y ago
Ah but this was a British system. You should have said "naught-naught-seven"