
All zeros in a bank card's CVC code - ElectronShak
https://security.stackexchange.com/questions/200243/all-0s-zeros-in-a-bank-cards-cvc-code
======
avar
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
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.

~~~
avar
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/01/27/pre-
authorization-and-post-authorization-part-1/)
[https://pciguru.wordpress.com/2018/02/17/pre-
authorization-a...](https://pciguru.wordpress.com/2018/02/17/pre-
authorization-and-post-authorization-part-2/)

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...](https://partnerhelp.booking.com/hc/en-
gb/articles/360000764307)

~~~
teilo
Thanks for that.

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

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

------
merty
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
Ah but this was a British system. You should have said "naught-naught-seven"

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

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

------
lazyjones
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
Couldn't you have just changed the PIN?

~~~
lazyjones
I asked, they couldn't...

~~~
BillinghamJ
You can just do it yourself at any ATM though?

~~~
gonzus
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
That's not the case. EU ATMs have that functionality too.

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

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

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

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

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

~~~
sokoloff
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
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
_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.

