All 0s (zeros) in a bank card's CVC code












225















My bank card recently expired. I got a new one and this one turned out to be "lucky": its CVC code was 000.



CVC code is 000



For a few months I used it extensively, both online and offline, without any difficulties - until the day when I entered my card details on Booking.com. I filled in the form, clicked "submit" - only to see the page discard the value in the CVC field and demand that I enter it again.



I contacted support. They confirmed that CVC code "000" is not acceptable because it is considered not secure enough (not an exact quote unfortunately, as the conversation was in Estonian), and they suggested that I order a new bank card where the CVC code would be different from "000".



That puzzled me. As a former tester, I'm quite used to situations where I think I'm reporting a bug and then I'm told it is actually a feature, but this time it was somewhat against common sense. My current work is also related to information security and I can think of three reasons their claim doesn't make sense:




  1. CVC is not just a random number, there is a certain algorithm of generating it. This, in turn, means that all values are equally probable and some certain numbers can't just be excluded from it.

  2. I have already used this card with a number of other online services, including Amazon Web Services, whose security is out of any doubts.

  3. I don't quite understand what "not secure enough" means. Are "111" or "999" secure enough? If not, how about "123" or "234"? Again, it's not something I pick myself, it's something I'm given by a bank, and if the bank thinks it's secure, then it must be treated as such.


Their response was very polite but not very helpful: "We totally understand your frustration and we are really sorry about causing you inconvenience. We handed your reasoning over to our management - they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery".



I forwarded the mail chain to my bank and asked for their advice. They told me they'd issue a new card for free, which solved the problem for me.



However, I still wonder:




  1. Are there any official regulations/prescriptions (from Visa/MC or elsewhere) or any best practices regarding "all-zero" CVC/CVV codes? Especially that bit about banks allegedly using 000 as an indication of a forgery - sounds like complete nonsense to me. I tried googling, but couldn't find anything.

  2. From a practical point of view, how reasonable it is to decline "000" as insecure? I listed my concerns above, but maybe I'm missing something?


Update: Tough choice on which answer to accept... I liked the answer from Alexander O'Mara a lot - it is detailed and to the point. The latest revision of Harper's answer also seems very reasonable. Yet I eventually decided to accept the answer by Zoey - it seems the most relevant, as it, besides everything else, also sheds some light on the internals of hotel business.



Thanks everyone for your answers and comments! What I'm going to do now is contact Booking.com support again and insist on getting this fixed. Will let you know about the outcome.










share|improve this question




















  • 92





    Your reasoning is entirely correct, that's the long and short of it. Looks like booking.com employs some moron managers (I bet this wasn't an engineering decision).

    – Luc
    Dec 22 '18 at 23:03






  • 124





    "they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery" I'd like to know why a bank would produce a forged card with 000 on it

    – Mike Caron
    Dec 23 '18 at 0:46






  • 22





    As a wild speculation, booking.com had a bug where the code could not tell the difference between somebody entering 000 and somebody leaving the field blank. Instead of fixing it properly they reject 000 as a CVC. The programmer should be fired, but you don't have that option. As I see it, you can either use a different vendor for hotels or call your bank and declare the card lost/stolen. They will issue a new card with a new number. With any luck the CVC will not be 000

    – Ross Millikan
    Dec 23 '18 at 15:52






  • 19





    @VladNikiforov If they aren't willing to fix it, simply write up this story on an appropriate website (e.g. medium.com), then share it on appropriate social media (e.g. /r/programming on reddit). The amount of shaming booking.com will get for their incompetence will force them to fix it.

    – Ian Kemp
    Dec 24 '18 at 14:01






  • 21





    Contact your card network (Visa/Mastercard) and file a complaint that the site maliciously refuses accepting your valid card. Visa has arguments big enough to make them fix their code. The site is displaying the logo under certain contract, and groundless refusal is probably violating it.

    – Agent_L
    Dec 27 '18 at 16:05


















225















My bank card recently expired. I got a new one and this one turned out to be "lucky": its CVC code was 000.



CVC code is 000



For a few months I used it extensively, both online and offline, without any difficulties - until the day when I entered my card details on Booking.com. I filled in the form, clicked "submit" - only to see the page discard the value in the CVC field and demand that I enter it again.



I contacted support. They confirmed that CVC code "000" is not acceptable because it is considered not secure enough (not an exact quote unfortunately, as the conversation was in Estonian), and they suggested that I order a new bank card where the CVC code would be different from "000".



That puzzled me. As a former tester, I'm quite used to situations where I think I'm reporting a bug and then I'm told it is actually a feature, but this time it was somewhat against common sense. My current work is also related to information security and I can think of three reasons their claim doesn't make sense:




  1. CVC is not just a random number, there is a certain algorithm of generating it. This, in turn, means that all values are equally probable and some certain numbers can't just be excluded from it.

  2. I have already used this card with a number of other online services, including Amazon Web Services, whose security is out of any doubts.

  3. I don't quite understand what "not secure enough" means. Are "111" or "999" secure enough? If not, how about "123" or "234"? Again, it's not something I pick myself, it's something I'm given by a bank, and if the bank thinks it's secure, then it must be treated as such.


Their response was very polite but not very helpful: "We totally understand your frustration and we are really sorry about causing you inconvenience. We handed your reasoning over to our management - they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery".



I forwarded the mail chain to my bank and asked for their advice. They told me they'd issue a new card for free, which solved the problem for me.



However, I still wonder:




  1. Are there any official regulations/prescriptions (from Visa/MC or elsewhere) or any best practices regarding "all-zero" CVC/CVV codes? Especially that bit about banks allegedly using 000 as an indication of a forgery - sounds like complete nonsense to me. I tried googling, but couldn't find anything.

  2. From a practical point of view, how reasonable it is to decline "000" as insecure? I listed my concerns above, but maybe I'm missing something?


Update: Tough choice on which answer to accept... I liked the answer from Alexander O'Mara a lot - it is detailed and to the point. The latest revision of Harper's answer also seems very reasonable. Yet I eventually decided to accept the answer by Zoey - it seems the most relevant, as it, besides everything else, also sheds some light on the internals of hotel business.



Thanks everyone for your answers and comments! What I'm going to do now is contact Booking.com support again and insist on getting this fixed. Will let you know about the outcome.










share|improve this question




















  • 92





    Your reasoning is entirely correct, that's the long and short of it. Looks like booking.com employs some moron managers (I bet this wasn't an engineering decision).

    – Luc
    Dec 22 '18 at 23:03






  • 124





    "they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery" I'd like to know why a bank would produce a forged card with 000 on it

    – Mike Caron
    Dec 23 '18 at 0:46






  • 22





    As a wild speculation, booking.com had a bug where the code could not tell the difference between somebody entering 000 and somebody leaving the field blank. Instead of fixing it properly they reject 000 as a CVC. The programmer should be fired, but you don't have that option. As I see it, you can either use a different vendor for hotels or call your bank and declare the card lost/stolen. They will issue a new card with a new number. With any luck the CVC will not be 000

    – Ross Millikan
    Dec 23 '18 at 15:52






  • 19





    @VladNikiforov If they aren't willing to fix it, simply write up this story on an appropriate website (e.g. medium.com), then share it on appropriate social media (e.g. /r/programming on reddit). The amount of shaming booking.com will get for their incompetence will force them to fix it.

    – Ian Kemp
    Dec 24 '18 at 14:01






  • 21





    Contact your card network (Visa/Mastercard) and file a complaint that the site maliciously refuses accepting your valid card. Visa has arguments big enough to make them fix their code. The site is displaying the logo under certain contract, and groundless refusal is probably violating it.

    – Agent_L
    Dec 27 '18 at 16:05
















225












225








225


57






My bank card recently expired. I got a new one and this one turned out to be "lucky": its CVC code was 000.



CVC code is 000



For a few months I used it extensively, both online and offline, without any difficulties - until the day when I entered my card details on Booking.com. I filled in the form, clicked "submit" - only to see the page discard the value in the CVC field and demand that I enter it again.



I contacted support. They confirmed that CVC code "000" is not acceptable because it is considered not secure enough (not an exact quote unfortunately, as the conversation was in Estonian), and they suggested that I order a new bank card where the CVC code would be different from "000".



That puzzled me. As a former tester, I'm quite used to situations where I think I'm reporting a bug and then I'm told it is actually a feature, but this time it was somewhat against common sense. My current work is also related to information security and I can think of three reasons their claim doesn't make sense:




  1. CVC is not just a random number, there is a certain algorithm of generating it. This, in turn, means that all values are equally probable and some certain numbers can't just be excluded from it.

  2. I have already used this card with a number of other online services, including Amazon Web Services, whose security is out of any doubts.

  3. I don't quite understand what "not secure enough" means. Are "111" or "999" secure enough? If not, how about "123" or "234"? Again, it's not something I pick myself, it's something I'm given by a bank, and if the bank thinks it's secure, then it must be treated as such.


Their response was very polite but not very helpful: "We totally understand your frustration and we are really sorry about causing you inconvenience. We handed your reasoning over to our management - they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery".



I forwarded the mail chain to my bank and asked for their advice. They told me they'd issue a new card for free, which solved the problem for me.



However, I still wonder:




  1. Are there any official regulations/prescriptions (from Visa/MC or elsewhere) or any best practices regarding "all-zero" CVC/CVV codes? Especially that bit about banks allegedly using 000 as an indication of a forgery - sounds like complete nonsense to me. I tried googling, but couldn't find anything.

  2. From a practical point of view, how reasonable it is to decline "000" as insecure? I listed my concerns above, but maybe I'm missing something?


Update: Tough choice on which answer to accept... I liked the answer from Alexander O'Mara a lot - it is detailed and to the point. The latest revision of Harper's answer also seems very reasonable. Yet I eventually decided to accept the answer by Zoey - it seems the most relevant, as it, besides everything else, also sheds some light on the internals of hotel business.



Thanks everyone for your answers and comments! What I'm going to do now is contact Booking.com support again and insist on getting this fixed. Will let you know about the outcome.










share|improve this question
















My bank card recently expired. I got a new one and this one turned out to be "lucky": its CVC code was 000.



CVC code is 000



For a few months I used it extensively, both online and offline, without any difficulties - until the day when I entered my card details on Booking.com. I filled in the form, clicked "submit" - only to see the page discard the value in the CVC field and demand that I enter it again.



I contacted support. They confirmed that CVC code "000" is not acceptable because it is considered not secure enough (not an exact quote unfortunately, as the conversation was in Estonian), and they suggested that I order a new bank card where the CVC code would be different from "000".



That puzzled me. As a former tester, I'm quite used to situations where I think I'm reporting a bug and then I'm told it is actually a feature, but this time it was somewhat against common sense. My current work is also related to information security and I can think of three reasons their claim doesn't make sense:




  1. CVC is not just a random number, there is a certain algorithm of generating it. This, in turn, means that all values are equally probable and some certain numbers can't just be excluded from it.

  2. I have already used this card with a number of other online services, including Amazon Web Services, whose security is out of any doubts.

  3. I don't quite understand what "not secure enough" means. Are "111" or "999" secure enough? If not, how about "123" or "234"? Again, it's not something I pick myself, it's something I'm given by a bank, and if the bank thinks it's secure, then it must be treated as such.


Their response was very polite but not very helpful: "We totally understand your frustration and we are really sorry about causing you inconvenience. We handed your reasoning over to our management - they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery".



I forwarded the mail chain to my bank and asked for their advice. They told me they'd issue a new card for free, which solved the problem for me.



However, I still wonder:




  1. Are there any official regulations/prescriptions (from Visa/MC or elsewhere) or any best practices regarding "all-zero" CVC/CVV codes? Especially that bit about banks allegedly using 000 as an indication of a forgery - sounds like complete nonsense to me. I tried googling, but couldn't find anything.

  2. From a practical point of view, how reasonable it is to decline "000" as insecure? I listed my concerns above, but maybe I'm missing something?


Update: Tough choice on which answer to accept... I liked the answer from Alexander O'Mara a lot - it is detailed and to the point. The latest revision of Harper's answer also seems very reasonable. Yet I eventually decided to accept the answer by Zoey - it seems the most relevant, as it, besides everything else, also sheds some light on the internals of hotel business.



Thanks everyone for your answers and comments! What I'm going to do now is contact Booking.com support again and insist on getting this fixed. Will let you know about the outcome.







credit-card






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 1 at 13:23









Uwe Keim

2,52721222




2,52721222










asked Dec 22 '18 at 20:30









Vlad NikiforovVlad Nikiforov

1,218238




1,218238








  • 92





    Your reasoning is entirely correct, that's the long and short of it. Looks like booking.com employs some moron managers (I bet this wasn't an engineering decision).

    – Luc
    Dec 22 '18 at 23:03






  • 124





    "they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery" I'd like to know why a bank would produce a forged card with 000 on it

    – Mike Caron
    Dec 23 '18 at 0:46






  • 22





    As a wild speculation, booking.com had a bug where the code could not tell the difference between somebody entering 000 and somebody leaving the field blank. Instead of fixing it properly they reject 000 as a CVC. The programmer should be fired, but you don't have that option. As I see it, you can either use a different vendor for hotels or call your bank and declare the card lost/stolen. They will issue a new card with a new number. With any luck the CVC will not be 000

    – Ross Millikan
    Dec 23 '18 at 15:52






  • 19





    @VladNikiforov If they aren't willing to fix it, simply write up this story on an appropriate website (e.g. medium.com), then share it on appropriate social media (e.g. /r/programming on reddit). The amount of shaming booking.com will get for their incompetence will force them to fix it.

    – Ian Kemp
    Dec 24 '18 at 14:01






  • 21





    Contact your card network (Visa/Mastercard) and file a complaint that the site maliciously refuses accepting your valid card. Visa has arguments big enough to make them fix their code. The site is displaying the logo under certain contract, and groundless refusal is probably violating it.

    – Agent_L
    Dec 27 '18 at 16:05
















  • 92





    Your reasoning is entirely correct, that's the long and short of it. Looks like booking.com employs some moron managers (I bet this wasn't an engineering decision).

    – Luc
    Dec 22 '18 at 23:03






  • 124





    "they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery" I'd like to know why a bank would produce a forged card with 000 on it

    – Mike Caron
    Dec 23 '18 at 0:46






  • 22





    As a wild speculation, booking.com had a bug where the code could not tell the difference between somebody entering 000 and somebody leaving the field blank. Instead of fixing it properly they reject 000 as a CVC. The programmer should be fired, but you don't have that option. As I see it, you can either use a different vendor for hotels or call your bank and declare the card lost/stolen. They will issue a new card with a new number. With any luck the CVC will not be 000

    – Ross Millikan
    Dec 23 '18 at 15:52






  • 19





    @VladNikiforov If they aren't willing to fix it, simply write up this story on an appropriate website (e.g. medium.com), then share it on appropriate social media (e.g. /r/programming on reddit). The amount of shaming booking.com will get for their incompetence will force them to fix it.

    – Ian Kemp
    Dec 24 '18 at 14:01






  • 21





    Contact your card network (Visa/Mastercard) and file a complaint that the site maliciously refuses accepting your valid card. Visa has arguments big enough to make them fix their code. The site is displaying the logo under certain contract, and groundless refusal is probably violating it.

    – Agent_L
    Dec 27 '18 at 16:05










92




92





Your reasoning is entirely correct, that's the long and short of it. Looks like booking.com employs some moron managers (I bet this wasn't an engineering decision).

– Luc
Dec 22 '18 at 23:03





Your reasoning is entirely correct, that's the long and short of it. Looks like booking.com employs some moron managers (I bet this wasn't an engineering decision).

– Luc
Dec 22 '18 at 23:03




124




124





"they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery" I'd like to know why a bank would produce a forged card with 000 on it

– Mike Caron
Dec 23 '18 at 0:46





"they responded that 000 is considered invalid, and this is also a way banks indicate that the card is a forgery" I'd like to know why a bank would produce a forged card with 000 on it

– Mike Caron
Dec 23 '18 at 0:46




22




22





As a wild speculation, booking.com had a bug where the code could not tell the difference between somebody entering 000 and somebody leaving the field blank. Instead of fixing it properly they reject 000 as a CVC. The programmer should be fired, but you don't have that option. As I see it, you can either use a different vendor for hotels or call your bank and declare the card lost/stolen. They will issue a new card with a new number. With any luck the CVC will not be 000

– Ross Millikan
Dec 23 '18 at 15:52





As a wild speculation, booking.com had a bug where the code could not tell the difference between somebody entering 000 and somebody leaving the field blank. Instead of fixing it properly they reject 000 as a CVC. The programmer should be fired, but you don't have that option. As I see it, you can either use a different vendor for hotels or call your bank and declare the card lost/stolen. They will issue a new card with a new number. With any luck the CVC will not be 000

– Ross Millikan
Dec 23 '18 at 15:52




19




19





@VladNikiforov If they aren't willing to fix it, simply write up this story on an appropriate website (e.g. medium.com), then share it on appropriate social media (e.g. /r/programming on reddit). The amount of shaming booking.com will get for their incompetence will force them to fix it.

– Ian Kemp
Dec 24 '18 at 14:01





@VladNikiforov If they aren't willing to fix it, simply write up this story on an appropriate website (e.g. medium.com), then share it on appropriate social media (e.g. /r/programming on reddit). The amount of shaming booking.com will get for their incompetence will force them to fix it.

– Ian Kemp
Dec 24 '18 at 14:01




21




21





Contact your card network (Visa/Mastercard) and file a complaint that the site maliciously refuses accepting your valid card. Visa has arguments big enough to make them fix their code. The site is displaying the logo under certain contract, and groundless refusal is probably violating it.

– Agent_L
Dec 27 '18 at 16:05







Contact your card network (Visa/Mastercard) and file a complaint that the site maliciously refuses accepting your valid card. Visa has arguments big enough to make them fix their code. The site is displaying the logo under certain contract, and groundless refusal is probably violating it.

– Agent_L
Dec 27 '18 at 16:05












7 Answers
7






active

oldest

votes


















179














Alexander O'Mara provided a correct answer, but having worked in a hotel that was using booking.com I believe I can provide additional information about the reason that CVV was denied.



Every day the hotel I worked in would receive around 50 bookings, a quarter of these bookings would be using fake credit card details, and about 90% of people using fake credit card details would not show up.



This resulted in a lot of guesswork when assigning rooms, we would often try to guess if the person will show up just based on their credit card details, and also sometimes take into consideration the name, location, how many days they will be staying, etc.
We would also try to call the day before to confirm bookings, so that these fake bookings result in a minimal interruption to the business.



Blocking CVV 000 is just booking.com's lazy attempt to reduce the amount of fake bookings. Some other CVVs are blocked as well.



The reason why booking.com blocks the CVV and other websites do not is because other websites generally attempt to charge the credit card immediately, while booking.com only forwards information to the hotels which charge the credit card on the day of arrival.






share|improve this answer





















  • 93





    Why on earth do hotels not pre-authorize the credit card? They could do as little as $1 (as is used for free trial verification) and immediately stop this issue--and that wouldn't cause the side effect of maxing out any low-limit or debit cards out there.

    – aidanh010
    Dec 23 '18 at 3:20






  • 80





    Are you saying a successful online platform like booking.com is not handling pre-authentication for their paying customers (aka hotels)?

    – eckes
    Dec 23 '18 at 12:13






  • 45





    But reading this comment, why on earth would a scammer give you 000 as the CVV? Since it's not checked beyond "000 looks suspicious", why not use 472 as the CVV or any one of the other 999 possible numbers?

    – gnasher729
    Dec 23 '18 at 18:17






  • 25





    This explanation about booking.com's handling of credit card data raises the question for me whether their process is actually PCI DSS compliant, or in violation thereof. One could argue that they do not do authorization and thus are not in violation ("Sensitive authentication data must not be stored after authorization (even if encrypted)."), but this would seem like a pretty bad way of dealing with sensitive credit card information...

    – Lucero
    Dec 23 '18 at 21:04






  • 98





    IMO, buggy validation like if (!(int(cvv) && checkCvv(cvv))) { return "It's not valid CVV" } is a much more likely explanation why this got rejected rather than being a deliberate security design decision.

    – Lie Ryan
    Dec 24 '18 at 1:49



















142














The only weak argument I can think of to reject such a CVV would be that if someone were trying to brute-force your 3-digit code, they might start with 000 first (but would they also reject 001?).




From practical point of view, how reasonable it is to decline "000" as insecure?




It's not really reasonable. Either you can charge the card with the provided CVC/CVV code or you can't. There's no good reason to reject this code, since it is valid, and you can't really be sure if a credit card's codes are valid until you actually try to charge it.



Sadly, poorly-designed input validation is all too common. Some developers have a tendency to just assume certain values are invalid without checking the spec, or not properly unit test their input validations.



Some examples include:




  • IP address 1.1.1.1

  • Version checking bugs like "10" < "9" if only the first character in the string is checking

  • Names with non-alpha character (like the apostrophe in my name)


It's also not uncommon that people in customer service will respond to your bug reports with something along the lines of "that's not a bug, it's a feature" without ever even consulting the developers.






share|improve this answer



















  • 166





    var cvv = parseInt(form.cvv); if(!cvv) markInvalid()

    – Mike Caron
    Dec 23 '18 at 0:47






  • 10





    The 1.1.1.1 thing is even worse, because the people knew that it was an IP address and decided they would unilaterally decide for the NIC that it would remain unused forever.

    – aidanh010
    Dec 23 '18 at 3:18






  • 32





    You can add email aliases (address+alias@example.com) to your examples list, very annoying when someone decides to be extra safe without a valid reason

    – Felipe Pereira
    Dec 23 '18 at 13:15






  • 23





    @gnasher729 it's also the reason why there wasn't any windows 9. Too many programs check if the OS is windows 95 or 98 by checking if "Windows 9" is in the OS' name.

    – Eric Duminil
    Dec 24 '18 at 12:34






  • 12





    My four-letter TLD causes email validation problems on some particularly stupid websites.

    – Lightness Races in Orbit
    Dec 25 '18 at 0:03



















87














This is a frame challenge of the company's claims. A random number in the range 000-999 is more secure than 001-998, rejecting values weakens it.



It's a software bug. They can't admit it.



Just one example: say, somewhere in the stack, they use a language with untyped variables (i.e. Where the same variable can hold 123.45, "late for dinner", a 0-character string, an "undefined" token, etc). It's commonplace to write this:



if ($CVC) # is CVC field present?



In an untyped language, a blank string evaluates to 0 (false) as the programmer intended, but so does 000! There are better ways to do that.



In this case, we know the problem is not in the public-facing web UI you use, but in the back-end platform that both of you share. The agent should open a bug on it in the ticketing system.



So why did they claim what they said? Because normal businesses are very reluctant to admit this kind of structural error that makes them look incompetent. But they also cannot send you off with an "I don't know", as that has the same effect. So they need to say something to you right now that feels sellable to them.



Obviously it is wrong; as proven by all the other people you do business with who have no problem with it. But try it yourself; try a competing booking platform and see how it goes.






share|improve this answer





















  • 15





    The string 000 doesn't evaluate false in Perl, Python or JavaScript.

    – Blrfl
    Dec 23 '18 at 20:40






  • 27





    Well, in JavaScript, if you compare "000" to false ("000" == false) with just 2 equals signs, it will evaluate to true.

    – Stefnotch
    Dec 23 '18 at 21:00






  • 8





    It's more likely a case of what Mike Caron says: if(!to_number(input)) reject(). The number zero is falsy in both Javascript and PHP.

    – John Dvorak
    Dec 23 '18 at 21:03








  • 9





    @Blrfl I think the main point is that there are possibilities on how a modern web stack could EASILY get broke on edge cases - purposely or accidentally. There is code on the back end, middle end, front end, etc that could ALL easily break on untested edge cases. JavaScript being the easiest culprit to point fingers at - but as my example about Mr. Null (his actual name) shows, it's hard to point fingers at JS when it could be any step. (I would say "you got bs'd" is a bad part of the answer... but the rest is valid)

    – WernerCD
    Dec 24 '18 at 3:20






  • 7





    @Blrfl I have information that's in agreement. Perl, Java, maybe Scala. Read the last paragraph of Isotopp's SE bio for an idea of how he knows :)

    – hobbs
    Dec 25 '18 at 7:51



















10














I currently have a credit card that arguably has a worse CVV number: 123



So far it has never been denied, but from a security point of view I don't like it as I feel like it could very well be the first thing a thief would type in if somehow they had my numbers but not my card.



From the website's point of view, IMHO it's asinine to purposely treat a valid number as invalid. (Even more so if the chances of it occurring are merely 1 in 1000.) Since it would be extremely easy for the site to attempt a very small authorization to confirm the credit card, or even let the hotel decide for themselves, I don't agree with the "preventing fake numbers" argument. That being said, a quick search yields quite a few people with the same issue on various websites over the years. So, you're not alone. :)






share|improve this answer



















  • 32





    I now know your CVV :) Now just gotta search public credit card breaches for... uhh... "TTT"?

    – rahuldottech
    Dec 28 '18 at 11:19



















5














In fairness, there are tens of thousands of hotel booking systems that booking.com have to pass information on to for them to process. I trust that booking.com can afford a developer who knows that (000) == FALSE in JavaScript... but is it worth their support time trying to diagnose the exact same bug for the hundreds of hotels who probably have this bug in their booking systems? Absolutely not.



My guess is that this is actually a rather reasonable attempt to mitigate data processing errors that happen further down the chain, and in systems that are out of booking.com's control.



As a card-processing merchant, they are obliged to process valid cards, so are probably breaking merchant rules here and could get in trouble with VISA (or whoever)... but i can almost see the logic.






share|improve this answer































    3














    I have some problems with the simple "stupid bug" theory here. I have no doubt that the person you were talking to was pulling this nonsense out of thin air (as some customer services people are wont to do). 000 is perfectly valid and you're no the first person on the internet to point out having the number.



    But there's a scale here that people aren't appreciating.




    • The natural possibility of getting 000 as your CVV is 0.1%

    • Booking.com is a business that generated $8 billion in raw 2017 revenue, most on card transactions. That's about a fifty thousand medium bookings a day.

    • Booking.com must therefore encounter 000 50 times a day. To a tune of $25k lost to Booking.com and, much, much more in terms of actual bookings not passed on.


    Rejecting 0.1% of card transactions is $9m in lost revenue. In the [very much smaller] businesses I work for, booking flow analytics would flag this up the chain pretty quickly. These sorts of companies (I tangentially work in holiday booking systems), the cart experience is the most tracked part... I'm finding it very hard to believe that a company that relies on analytics would miss something as simple as a card validation issue.



    So if we assume that this cannot exist at that scale, we have to offer some suggestions that limit the scope...





    1. This is a local bug.



      Many multinationals put money through local accounts and bounce it around from there for tax purposes. It may be that Booking.com allows its local offices to edit the code on this to handle local quirks (currency, whole payment schemes that aren't global) and in doing so, allowing bugs to creep in that don't exist elsewhere.



      The possibility of this is increased because the target country is Croatia. They use the Kuna there, not the Euro. There may well be a raft of accounting differences and mechanism providers.



      That also goes some distance to explain why this has gone under the radar. 0.1% of Croatia-bound money is going to be a hell of a lot less than the global income.




    2. 000 isn't as common as 0.1%



      As JPhi1618 points out in the comments, the other scope-limiting factor is that perhaps banks don't issue 000 very often. There's no reason they shouldn't and as I've said, there is evidence online of other people with 000 cards, but that is not to say it is common.



      I have no way to verify this. Perhaps somebody with a card processing log that includes CVVs can run an analysis.




    Still, if you find issues like this, report them. Skip the customer services team because they simply don't know what's going on. Go to the CEO, or security team as they're both going to take this pretty seriously for slightly different reasons. $9m in lost revenue is a good motivator.






    share|improve this answer


























    • Just a note: I was trying to book a hotel in Croatia, which is not a Euro country, so your reasoning may be correct.

      – Vlad Nikiforov
      Jan 2 at 15:30






    • 2





      I think using your logic shows that if this 000 number was as common as expected, Booking.com would be forced to fix the issue. They aren't going to miss out on 1 out of 1000 bookings because of a very trivial thing to fix. So, I think that most credit card companies don't use 000 and the bank OP is using is an outlier.

      – JPhi1618
      Jan 2 at 16:39






    • 2





      @JPhi1618 outlier? I don't think so. A few years ago I had a VISA card from a major French bank with 000 as CVC code (now expired). Used it all its lifetime without a hitch. Never tried booking.com. My guess: they indeed lose 0.1% of their revenue. Reaching CEO of an established company is probably difficult, security team wouldn't care, current state is not a security breach.

      – Stéphane Gourichon
      Jan 2 at 22:58











    • "Reaching CEO of an established company is probably difficult". It used to be but at some point in the last 15 years it seems to have become fashionable for executives to be seen being hands-on with problems. Even if you can't talk directly, many have an internal escalation pathway. But if this is something local —as it seems it might— it might be difficult to bounce this to the right place. And ultimately the appetite for fixing 0.1% of payments through to Croatia (they use Kuna, not Euro, so possibly local code) will be somewhat lighter.

      – Oli
      Jan 3 at 9:57



















    0














    Note that on some Credit Card software, a CVC with the magic value 000 means that a CVC was provided but has been deleted since (due to PCI constraints). That's probably what Booking is doing, and that explains why they don't accept it.



    Tough luck :/






    share|improve this answer























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "162"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f200243%2fall-0s-zeros-in-a-bank-cards-cvc-code%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      7 Answers
      7






      active

      oldest

      votes








      7 Answers
      7






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      179














      Alexander O'Mara provided a correct answer, but having worked in a hotel that was using booking.com I believe I can provide additional information about the reason that CVV was denied.



      Every day the hotel I worked in would receive around 50 bookings, a quarter of these bookings would be using fake credit card details, and about 90% of people using fake credit card details would not show up.



      This resulted in a lot of guesswork when assigning rooms, we would often try to guess if the person will show up just based on their credit card details, and also sometimes take into consideration the name, location, how many days they will be staying, etc.
      We would also try to call the day before to confirm bookings, so that these fake bookings result in a minimal interruption to the business.



      Blocking CVV 000 is just booking.com's lazy attempt to reduce the amount of fake bookings. Some other CVVs are blocked as well.



      The reason why booking.com blocks the CVV and other websites do not is because other websites generally attempt to charge the credit card immediately, while booking.com only forwards information to the hotels which charge the credit card on the day of arrival.






      share|improve this answer





















      • 93





        Why on earth do hotels not pre-authorize the credit card? They could do as little as $1 (as is used for free trial verification) and immediately stop this issue--and that wouldn't cause the side effect of maxing out any low-limit or debit cards out there.

        – aidanh010
        Dec 23 '18 at 3:20






      • 80





        Are you saying a successful online platform like booking.com is not handling pre-authentication for their paying customers (aka hotels)?

        – eckes
        Dec 23 '18 at 12:13






      • 45





        But reading this comment, why on earth would a scammer give you 000 as the CVV? Since it's not checked beyond "000 looks suspicious", why not use 472 as the CVV or any one of the other 999 possible numbers?

        – gnasher729
        Dec 23 '18 at 18:17






      • 25





        This explanation about booking.com's handling of credit card data raises the question for me whether their process is actually PCI DSS compliant, or in violation thereof. One could argue that they do not do authorization and thus are not in violation ("Sensitive authentication data must not be stored after authorization (even if encrypted)."), but this would seem like a pretty bad way of dealing with sensitive credit card information...

        – Lucero
        Dec 23 '18 at 21:04






      • 98





        IMO, buggy validation like if (!(int(cvv) && checkCvv(cvv))) { return "It's not valid CVV" } is a much more likely explanation why this got rejected rather than being a deliberate security design decision.

        – Lie Ryan
        Dec 24 '18 at 1:49
















      179














      Alexander O'Mara provided a correct answer, but having worked in a hotel that was using booking.com I believe I can provide additional information about the reason that CVV was denied.



      Every day the hotel I worked in would receive around 50 bookings, a quarter of these bookings would be using fake credit card details, and about 90% of people using fake credit card details would not show up.



      This resulted in a lot of guesswork when assigning rooms, we would often try to guess if the person will show up just based on their credit card details, and also sometimes take into consideration the name, location, how many days they will be staying, etc.
      We would also try to call the day before to confirm bookings, so that these fake bookings result in a minimal interruption to the business.



      Blocking CVV 000 is just booking.com's lazy attempt to reduce the amount of fake bookings. Some other CVVs are blocked as well.



      The reason why booking.com blocks the CVV and other websites do not is because other websites generally attempt to charge the credit card immediately, while booking.com only forwards information to the hotels which charge the credit card on the day of arrival.






      share|improve this answer





















      • 93





        Why on earth do hotels not pre-authorize the credit card? They could do as little as $1 (as is used for free trial verification) and immediately stop this issue--and that wouldn't cause the side effect of maxing out any low-limit or debit cards out there.

        – aidanh010
        Dec 23 '18 at 3:20






      • 80





        Are you saying a successful online platform like booking.com is not handling pre-authentication for their paying customers (aka hotels)?

        – eckes
        Dec 23 '18 at 12:13






      • 45





        But reading this comment, why on earth would a scammer give you 000 as the CVV? Since it's not checked beyond "000 looks suspicious", why not use 472 as the CVV or any one of the other 999 possible numbers?

        – gnasher729
        Dec 23 '18 at 18:17






      • 25





        This explanation about booking.com's handling of credit card data raises the question for me whether their process is actually PCI DSS compliant, or in violation thereof. One could argue that they do not do authorization and thus are not in violation ("Sensitive authentication data must not be stored after authorization (even if encrypted)."), but this would seem like a pretty bad way of dealing with sensitive credit card information...

        – Lucero
        Dec 23 '18 at 21:04






      • 98





        IMO, buggy validation like if (!(int(cvv) && checkCvv(cvv))) { return "It's not valid CVV" } is a much more likely explanation why this got rejected rather than being a deliberate security design decision.

        – Lie Ryan
        Dec 24 '18 at 1:49














      179












      179








      179







      Alexander O'Mara provided a correct answer, but having worked in a hotel that was using booking.com I believe I can provide additional information about the reason that CVV was denied.



      Every day the hotel I worked in would receive around 50 bookings, a quarter of these bookings would be using fake credit card details, and about 90% of people using fake credit card details would not show up.



      This resulted in a lot of guesswork when assigning rooms, we would often try to guess if the person will show up just based on their credit card details, and also sometimes take into consideration the name, location, how many days they will be staying, etc.
      We would also try to call the day before to confirm bookings, so that these fake bookings result in a minimal interruption to the business.



      Blocking CVV 000 is just booking.com's lazy attempt to reduce the amount of fake bookings. Some other CVVs are blocked as well.



      The reason why booking.com blocks the CVV and other websites do not is because other websites generally attempt to charge the credit card immediately, while booking.com only forwards information to the hotels which charge the credit card on the day of arrival.






      share|improve this answer















      Alexander O'Mara provided a correct answer, but having worked in a hotel that was using booking.com I believe I can provide additional information about the reason that CVV was denied.



      Every day the hotel I worked in would receive around 50 bookings, a quarter of these bookings would be using fake credit card details, and about 90% of people using fake credit card details would not show up.



      This resulted in a lot of guesswork when assigning rooms, we would often try to guess if the person will show up just based on their credit card details, and also sometimes take into consideration the name, location, how many days they will be staying, etc.
      We would also try to call the day before to confirm bookings, so that these fake bookings result in a minimal interruption to the business.



      Blocking CVV 000 is just booking.com's lazy attempt to reduce the amount of fake bookings. Some other CVVs are blocked as well.



      The reason why booking.com blocks the CVV and other websites do not is because other websites generally attempt to charge the credit card immediately, while booking.com only forwards information to the hotels which charge the credit card on the day of arrival.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Dec 27 '18 at 16:08









      yoozer8

      1681211




      1681211










      answered Dec 23 '18 at 1:21









      ZoeyZoey

      1,581147




      1,581147








      • 93





        Why on earth do hotels not pre-authorize the credit card? They could do as little as $1 (as is used for free trial verification) and immediately stop this issue--and that wouldn't cause the side effect of maxing out any low-limit or debit cards out there.

        – aidanh010
        Dec 23 '18 at 3:20






      • 80





        Are you saying a successful online platform like booking.com is not handling pre-authentication for their paying customers (aka hotels)?

        – eckes
        Dec 23 '18 at 12:13






      • 45





        But reading this comment, why on earth would a scammer give you 000 as the CVV? Since it's not checked beyond "000 looks suspicious", why not use 472 as the CVV or any one of the other 999 possible numbers?

        – gnasher729
        Dec 23 '18 at 18:17






      • 25





        This explanation about booking.com's handling of credit card data raises the question for me whether their process is actually PCI DSS compliant, or in violation thereof. One could argue that they do not do authorization and thus are not in violation ("Sensitive authentication data must not be stored after authorization (even if encrypted)."), but this would seem like a pretty bad way of dealing with sensitive credit card information...

        – Lucero
        Dec 23 '18 at 21:04






      • 98





        IMO, buggy validation like if (!(int(cvv) && checkCvv(cvv))) { return "It's not valid CVV" } is a much more likely explanation why this got rejected rather than being a deliberate security design decision.

        – Lie Ryan
        Dec 24 '18 at 1:49














      • 93





        Why on earth do hotels not pre-authorize the credit card? They could do as little as $1 (as is used for free trial verification) and immediately stop this issue--and that wouldn't cause the side effect of maxing out any low-limit or debit cards out there.

        – aidanh010
        Dec 23 '18 at 3:20






      • 80





        Are you saying a successful online platform like booking.com is not handling pre-authentication for their paying customers (aka hotels)?

        – eckes
        Dec 23 '18 at 12:13






      • 45





        But reading this comment, why on earth would a scammer give you 000 as the CVV? Since it's not checked beyond "000 looks suspicious", why not use 472 as the CVV or any one of the other 999 possible numbers?

        – gnasher729
        Dec 23 '18 at 18:17






      • 25





        This explanation about booking.com's handling of credit card data raises the question for me whether their process is actually PCI DSS compliant, or in violation thereof. One could argue that they do not do authorization and thus are not in violation ("Sensitive authentication data must not be stored after authorization (even if encrypted)."), but this would seem like a pretty bad way of dealing with sensitive credit card information...

        – Lucero
        Dec 23 '18 at 21:04






      • 98





        IMO, buggy validation like if (!(int(cvv) && checkCvv(cvv))) { return "It's not valid CVV" } is a much more likely explanation why this got rejected rather than being a deliberate security design decision.

        – Lie Ryan
        Dec 24 '18 at 1:49








      93




      93





      Why on earth do hotels not pre-authorize the credit card? They could do as little as $1 (as is used for free trial verification) and immediately stop this issue--and that wouldn't cause the side effect of maxing out any low-limit or debit cards out there.

      – aidanh010
      Dec 23 '18 at 3:20





      Why on earth do hotels not pre-authorize the credit card? They could do as little as $1 (as is used for free trial verification) and immediately stop this issue--and that wouldn't cause the side effect of maxing out any low-limit or debit cards out there.

      – aidanh010
      Dec 23 '18 at 3:20




      80




      80





      Are you saying a successful online platform like booking.com is not handling pre-authentication for their paying customers (aka hotels)?

      – eckes
      Dec 23 '18 at 12:13





      Are you saying a successful online platform like booking.com is not handling pre-authentication for their paying customers (aka hotels)?

      – eckes
      Dec 23 '18 at 12:13




      45




      45





      But reading this comment, why on earth would a scammer give you 000 as the CVV? Since it's not checked beyond "000 looks suspicious", why not use 472 as the CVV or any one of the other 999 possible numbers?

      – gnasher729
      Dec 23 '18 at 18:17





      But reading this comment, why on earth would a scammer give you 000 as the CVV? Since it's not checked beyond "000 looks suspicious", why not use 472 as the CVV or any one of the other 999 possible numbers?

      – gnasher729
      Dec 23 '18 at 18:17




      25




      25





      This explanation about booking.com's handling of credit card data raises the question for me whether their process is actually PCI DSS compliant, or in violation thereof. One could argue that they do not do authorization and thus are not in violation ("Sensitive authentication data must not be stored after authorization (even if encrypted)."), but this would seem like a pretty bad way of dealing with sensitive credit card information...

      – Lucero
      Dec 23 '18 at 21:04





      This explanation about booking.com's handling of credit card data raises the question for me whether their process is actually PCI DSS compliant, or in violation thereof. One could argue that they do not do authorization and thus are not in violation ("Sensitive authentication data must not be stored after authorization (even if encrypted)."), but this would seem like a pretty bad way of dealing with sensitive credit card information...

      – Lucero
      Dec 23 '18 at 21:04




      98




      98





      IMO, buggy validation like if (!(int(cvv) && checkCvv(cvv))) { return "It's not valid CVV" } is a much more likely explanation why this got rejected rather than being a deliberate security design decision.

      – Lie Ryan
      Dec 24 '18 at 1:49





      IMO, buggy validation like if (!(int(cvv) && checkCvv(cvv))) { return "It's not valid CVV" } is a much more likely explanation why this got rejected rather than being a deliberate security design decision.

      – Lie Ryan
      Dec 24 '18 at 1:49













      142














      The only weak argument I can think of to reject such a CVV would be that if someone were trying to brute-force your 3-digit code, they might start with 000 first (but would they also reject 001?).




      From practical point of view, how reasonable it is to decline "000" as insecure?




      It's not really reasonable. Either you can charge the card with the provided CVC/CVV code or you can't. There's no good reason to reject this code, since it is valid, and you can't really be sure if a credit card's codes are valid until you actually try to charge it.



      Sadly, poorly-designed input validation is all too common. Some developers have a tendency to just assume certain values are invalid without checking the spec, or not properly unit test their input validations.



      Some examples include:




      • IP address 1.1.1.1

      • Version checking bugs like "10" < "9" if only the first character in the string is checking

      • Names with non-alpha character (like the apostrophe in my name)


      It's also not uncommon that people in customer service will respond to your bug reports with something along the lines of "that's not a bug, it's a feature" without ever even consulting the developers.






      share|improve this answer



















      • 166





        var cvv = parseInt(form.cvv); if(!cvv) markInvalid()

        – Mike Caron
        Dec 23 '18 at 0:47






      • 10





        The 1.1.1.1 thing is even worse, because the people knew that it was an IP address and decided they would unilaterally decide for the NIC that it would remain unused forever.

        – aidanh010
        Dec 23 '18 at 3:18






      • 32





        You can add email aliases (address+alias@example.com) to your examples list, very annoying when someone decides to be extra safe without a valid reason

        – Felipe Pereira
        Dec 23 '18 at 13:15






      • 23





        @gnasher729 it's also the reason why there wasn't any windows 9. Too many programs check if the OS is windows 95 or 98 by checking if "Windows 9" is in the OS' name.

        – Eric Duminil
        Dec 24 '18 at 12:34






      • 12





        My four-letter TLD causes email validation problems on some particularly stupid websites.

        – Lightness Races in Orbit
        Dec 25 '18 at 0:03
















      142














      The only weak argument I can think of to reject such a CVV would be that if someone were trying to brute-force your 3-digit code, they might start with 000 first (but would they also reject 001?).




      From practical point of view, how reasonable it is to decline "000" as insecure?




      It's not really reasonable. Either you can charge the card with the provided CVC/CVV code or you can't. There's no good reason to reject this code, since it is valid, and you can't really be sure if a credit card's codes are valid until you actually try to charge it.



      Sadly, poorly-designed input validation is all too common. Some developers have a tendency to just assume certain values are invalid without checking the spec, or not properly unit test their input validations.



      Some examples include:




      • IP address 1.1.1.1

      • Version checking bugs like "10" < "9" if only the first character in the string is checking

      • Names with non-alpha character (like the apostrophe in my name)


      It's also not uncommon that people in customer service will respond to your bug reports with something along the lines of "that's not a bug, it's a feature" without ever even consulting the developers.






      share|improve this answer



















      • 166





        var cvv = parseInt(form.cvv); if(!cvv) markInvalid()

        – Mike Caron
        Dec 23 '18 at 0:47






      • 10





        The 1.1.1.1 thing is even worse, because the people knew that it was an IP address and decided they would unilaterally decide for the NIC that it would remain unused forever.

        – aidanh010
        Dec 23 '18 at 3:18






      • 32





        You can add email aliases (address+alias@example.com) to your examples list, very annoying when someone decides to be extra safe without a valid reason

        – Felipe Pereira
        Dec 23 '18 at 13:15






      • 23





        @gnasher729 it's also the reason why there wasn't any windows 9. Too many programs check if the OS is windows 95 or 98 by checking if "Windows 9" is in the OS' name.

        – Eric Duminil
        Dec 24 '18 at 12:34






      • 12





        My four-letter TLD causes email validation problems on some particularly stupid websites.

        – Lightness Races in Orbit
        Dec 25 '18 at 0:03














      142












      142








      142







      The only weak argument I can think of to reject such a CVV would be that if someone were trying to brute-force your 3-digit code, they might start with 000 first (but would they also reject 001?).




      From practical point of view, how reasonable it is to decline "000" as insecure?




      It's not really reasonable. Either you can charge the card with the provided CVC/CVV code or you can't. There's no good reason to reject this code, since it is valid, and you can't really be sure if a credit card's codes are valid until you actually try to charge it.



      Sadly, poorly-designed input validation is all too common. Some developers have a tendency to just assume certain values are invalid without checking the spec, or not properly unit test their input validations.



      Some examples include:




      • IP address 1.1.1.1

      • Version checking bugs like "10" < "9" if only the first character in the string is checking

      • Names with non-alpha character (like the apostrophe in my name)


      It's also not uncommon that people in customer service will respond to your bug reports with something along the lines of "that's not a bug, it's a feature" without ever even consulting the developers.






      share|improve this answer













      The only weak argument I can think of to reject such a CVV would be that if someone were trying to brute-force your 3-digit code, they might start with 000 first (but would they also reject 001?).




      From practical point of view, how reasonable it is to decline "000" as insecure?




      It's not really reasonable. Either you can charge the card with the provided CVC/CVV code or you can't. There's no good reason to reject this code, since it is valid, and you can't really be sure if a credit card's codes are valid until you actually try to charge it.



      Sadly, poorly-designed input validation is all too common. Some developers have a tendency to just assume certain values are invalid without checking the spec, or not properly unit test their input validations.



      Some examples include:




      • IP address 1.1.1.1

      • Version checking bugs like "10" < "9" if only the first character in the string is checking

      • Names with non-alpha character (like the apostrophe in my name)


      It's also not uncommon that people in customer service will respond to your bug reports with something along the lines of "that's not a bug, it's a feature" without ever even consulting the developers.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Dec 22 '18 at 21:57









      Alexander O'MaraAlexander O'Mara

      7,87452734




      7,87452734








      • 166





        var cvv = parseInt(form.cvv); if(!cvv) markInvalid()

        – Mike Caron
        Dec 23 '18 at 0:47






      • 10





        The 1.1.1.1 thing is even worse, because the people knew that it was an IP address and decided they would unilaterally decide for the NIC that it would remain unused forever.

        – aidanh010
        Dec 23 '18 at 3:18






      • 32





        You can add email aliases (address+alias@example.com) to your examples list, very annoying when someone decides to be extra safe without a valid reason

        – Felipe Pereira
        Dec 23 '18 at 13:15






      • 23





        @gnasher729 it's also the reason why there wasn't any windows 9. Too many programs check if the OS is windows 95 or 98 by checking if "Windows 9" is in the OS' name.

        – Eric Duminil
        Dec 24 '18 at 12:34






      • 12





        My four-letter TLD causes email validation problems on some particularly stupid websites.

        – Lightness Races in Orbit
        Dec 25 '18 at 0:03














      • 166





        var cvv = parseInt(form.cvv); if(!cvv) markInvalid()

        – Mike Caron
        Dec 23 '18 at 0:47






      • 10





        The 1.1.1.1 thing is even worse, because the people knew that it was an IP address and decided they would unilaterally decide for the NIC that it would remain unused forever.

        – aidanh010
        Dec 23 '18 at 3:18






      • 32





        You can add email aliases (address+alias@example.com) to your examples list, very annoying when someone decides to be extra safe without a valid reason

        – Felipe Pereira
        Dec 23 '18 at 13:15






      • 23





        @gnasher729 it's also the reason why there wasn't any windows 9. Too many programs check if the OS is windows 95 or 98 by checking if "Windows 9" is in the OS' name.

        – Eric Duminil
        Dec 24 '18 at 12:34






      • 12





        My four-letter TLD causes email validation problems on some particularly stupid websites.

        – Lightness Races in Orbit
        Dec 25 '18 at 0:03








      166




      166





      var cvv = parseInt(form.cvv); if(!cvv) markInvalid()

      – Mike Caron
      Dec 23 '18 at 0:47





      var cvv = parseInt(form.cvv); if(!cvv) markInvalid()

      – Mike Caron
      Dec 23 '18 at 0:47




      10




      10





      The 1.1.1.1 thing is even worse, because the people knew that it was an IP address and decided they would unilaterally decide for the NIC that it would remain unused forever.

      – aidanh010
      Dec 23 '18 at 3:18





      The 1.1.1.1 thing is even worse, because the people knew that it was an IP address and decided they would unilaterally decide for the NIC that it would remain unused forever.

      – aidanh010
      Dec 23 '18 at 3:18




      32




      32





      You can add email aliases (address+alias@example.com) to your examples list, very annoying when someone decides to be extra safe without a valid reason

      – Felipe Pereira
      Dec 23 '18 at 13:15





      You can add email aliases (address+alias@example.com) to your examples list, very annoying when someone decides to be extra safe without a valid reason

      – Felipe Pereira
      Dec 23 '18 at 13:15




      23




      23





      @gnasher729 it's also the reason why there wasn't any windows 9. Too many programs check if the OS is windows 95 or 98 by checking if "Windows 9" is in the OS' name.

      – Eric Duminil
      Dec 24 '18 at 12:34





      @gnasher729 it's also the reason why there wasn't any windows 9. Too many programs check if the OS is windows 95 or 98 by checking if "Windows 9" is in the OS' name.

      – Eric Duminil
      Dec 24 '18 at 12:34




      12




      12





      My four-letter TLD causes email validation problems on some particularly stupid websites.

      – Lightness Races in Orbit
      Dec 25 '18 at 0:03





      My four-letter TLD causes email validation problems on some particularly stupid websites.

      – Lightness Races in Orbit
      Dec 25 '18 at 0:03











      87














      This is a frame challenge of the company's claims. A random number in the range 000-999 is more secure than 001-998, rejecting values weakens it.



      It's a software bug. They can't admit it.



      Just one example: say, somewhere in the stack, they use a language with untyped variables (i.e. Where the same variable can hold 123.45, "late for dinner", a 0-character string, an "undefined" token, etc). It's commonplace to write this:



      if ($CVC) # is CVC field present?



      In an untyped language, a blank string evaluates to 0 (false) as the programmer intended, but so does 000! There are better ways to do that.



      In this case, we know the problem is not in the public-facing web UI you use, but in the back-end platform that both of you share. The agent should open a bug on it in the ticketing system.



      So why did they claim what they said? Because normal businesses are very reluctant to admit this kind of structural error that makes them look incompetent. But they also cannot send you off with an "I don't know", as that has the same effect. So they need to say something to you right now that feels sellable to them.



      Obviously it is wrong; as proven by all the other people you do business with who have no problem with it. But try it yourself; try a competing booking platform and see how it goes.






      share|improve this answer





















      • 15





        The string 000 doesn't evaluate false in Perl, Python or JavaScript.

        – Blrfl
        Dec 23 '18 at 20:40






      • 27





        Well, in JavaScript, if you compare "000" to false ("000" == false) with just 2 equals signs, it will evaluate to true.

        – Stefnotch
        Dec 23 '18 at 21:00






      • 8





        It's more likely a case of what Mike Caron says: if(!to_number(input)) reject(). The number zero is falsy in both Javascript and PHP.

        – John Dvorak
        Dec 23 '18 at 21:03








      • 9





        @Blrfl I think the main point is that there are possibilities on how a modern web stack could EASILY get broke on edge cases - purposely or accidentally. There is code on the back end, middle end, front end, etc that could ALL easily break on untested edge cases. JavaScript being the easiest culprit to point fingers at - but as my example about Mr. Null (his actual name) shows, it's hard to point fingers at JS when it could be any step. (I would say "you got bs'd" is a bad part of the answer... but the rest is valid)

        – WernerCD
        Dec 24 '18 at 3:20






      • 7





        @Blrfl I have information that's in agreement. Perl, Java, maybe Scala. Read the last paragraph of Isotopp's SE bio for an idea of how he knows :)

        – hobbs
        Dec 25 '18 at 7:51
















      87














      This is a frame challenge of the company's claims. A random number in the range 000-999 is more secure than 001-998, rejecting values weakens it.



      It's a software bug. They can't admit it.



      Just one example: say, somewhere in the stack, they use a language with untyped variables (i.e. Where the same variable can hold 123.45, "late for dinner", a 0-character string, an "undefined" token, etc). It's commonplace to write this:



      if ($CVC) # is CVC field present?



      In an untyped language, a blank string evaluates to 0 (false) as the programmer intended, but so does 000! There are better ways to do that.



      In this case, we know the problem is not in the public-facing web UI you use, but in the back-end platform that both of you share. The agent should open a bug on it in the ticketing system.



      So why did they claim what they said? Because normal businesses are very reluctant to admit this kind of structural error that makes them look incompetent. But they also cannot send you off with an "I don't know", as that has the same effect. So they need to say something to you right now that feels sellable to them.



      Obviously it is wrong; as proven by all the other people you do business with who have no problem with it. But try it yourself; try a competing booking platform and see how it goes.






      share|improve this answer





















      • 15





        The string 000 doesn't evaluate false in Perl, Python or JavaScript.

        – Blrfl
        Dec 23 '18 at 20:40






      • 27





        Well, in JavaScript, if you compare "000" to false ("000" == false) with just 2 equals signs, it will evaluate to true.

        – Stefnotch
        Dec 23 '18 at 21:00






      • 8





        It's more likely a case of what Mike Caron says: if(!to_number(input)) reject(). The number zero is falsy in both Javascript and PHP.

        – John Dvorak
        Dec 23 '18 at 21:03








      • 9





        @Blrfl I think the main point is that there are possibilities on how a modern web stack could EASILY get broke on edge cases - purposely or accidentally. There is code on the back end, middle end, front end, etc that could ALL easily break on untested edge cases. JavaScript being the easiest culprit to point fingers at - but as my example about Mr. Null (his actual name) shows, it's hard to point fingers at JS when it could be any step. (I would say "you got bs'd" is a bad part of the answer... but the rest is valid)

        – WernerCD
        Dec 24 '18 at 3:20






      • 7





        @Blrfl I have information that's in agreement. Perl, Java, maybe Scala. Read the last paragraph of Isotopp's SE bio for an idea of how he knows :)

        – hobbs
        Dec 25 '18 at 7:51














      87












      87








      87







      This is a frame challenge of the company's claims. A random number in the range 000-999 is more secure than 001-998, rejecting values weakens it.



      It's a software bug. They can't admit it.



      Just one example: say, somewhere in the stack, they use a language with untyped variables (i.e. Where the same variable can hold 123.45, "late for dinner", a 0-character string, an "undefined" token, etc). It's commonplace to write this:



      if ($CVC) # is CVC field present?



      In an untyped language, a blank string evaluates to 0 (false) as the programmer intended, but so does 000! There are better ways to do that.



      In this case, we know the problem is not in the public-facing web UI you use, but in the back-end platform that both of you share. The agent should open a bug on it in the ticketing system.



      So why did they claim what they said? Because normal businesses are very reluctant to admit this kind of structural error that makes them look incompetent. But they also cannot send you off with an "I don't know", as that has the same effect. So they need to say something to you right now that feels sellable to them.



      Obviously it is wrong; as proven by all the other people you do business with who have no problem with it. But try it yourself; try a competing booking platform and see how it goes.






      share|improve this answer















      This is a frame challenge of the company's claims. A random number in the range 000-999 is more secure than 001-998, rejecting values weakens it.



      It's a software bug. They can't admit it.



      Just one example: say, somewhere in the stack, they use a language with untyped variables (i.e. Where the same variable can hold 123.45, "late for dinner", a 0-character string, an "undefined" token, etc). It's commonplace to write this:



      if ($CVC) # is CVC field present?



      In an untyped language, a blank string evaluates to 0 (false) as the programmer intended, but so does 000! There are better ways to do that.



      In this case, we know the problem is not in the public-facing web UI you use, but in the back-end platform that both of you share. The agent should open a bug on it in the ticketing system.



      So why did they claim what they said? Because normal businesses are very reluctant to admit this kind of structural error that makes them look incompetent. But they also cannot send you off with an "I don't know", as that has the same effect. So they need to say something to you right now that feels sellable to them.



      Obviously it is wrong; as proven by all the other people you do business with who have no problem with it. But try it yourself; try a competing booking platform and see how it goes.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Dec 24 '18 at 17:48

























      answered Dec 23 '18 at 19:42









      HarperHarper

      2,000413




      2,000413








      • 15





        The string 000 doesn't evaluate false in Perl, Python or JavaScript.

        – Blrfl
        Dec 23 '18 at 20:40






      • 27





        Well, in JavaScript, if you compare "000" to false ("000" == false) with just 2 equals signs, it will evaluate to true.

        – Stefnotch
        Dec 23 '18 at 21:00






      • 8





        It's more likely a case of what Mike Caron says: if(!to_number(input)) reject(). The number zero is falsy in both Javascript and PHP.

        – John Dvorak
        Dec 23 '18 at 21:03








      • 9





        @Blrfl I think the main point is that there are possibilities on how a modern web stack could EASILY get broke on edge cases - purposely or accidentally. There is code on the back end, middle end, front end, etc that could ALL easily break on untested edge cases. JavaScript being the easiest culprit to point fingers at - but as my example about Mr. Null (his actual name) shows, it's hard to point fingers at JS when it could be any step. (I would say "you got bs'd" is a bad part of the answer... but the rest is valid)

        – WernerCD
        Dec 24 '18 at 3:20






      • 7





        @Blrfl I have information that's in agreement. Perl, Java, maybe Scala. Read the last paragraph of Isotopp's SE bio for an idea of how he knows :)

        – hobbs
        Dec 25 '18 at 7:51














      • 15





        The string 000 doesn't evaluate false in Perl, Python or JavaScript.

        – Blrfl
        Dec 23 '18 at 20:40






      • 27





        Well, in JavaScript, if you compare "000" to false ("000" == false) with just 2 equals signs, it will evaluate to true.

        – Stefnotch
        Dec 23 '18 at 21:00






      • 8





        It's more likely a case of what Mike Caron says: if(!to_number(input)) reject(). The number zero is falsy in both Javascript and PHP.

        – John Dvorak
        Dec 23 '18 at 21:03








      • 9





        @Blrfl I think the main point is that there are possibilities on how a modern web stack could EASILY get broke on edge cases - purposely or accidentally. There is code on the back end, middle end, front end, etc that could ALL easily break on untested edge cases. JavaScript being the easiest culprit to point fingers at - but as my example about Mr. Null (his actual name) shows, it's hard to point fingers at JS when it could be any step. (I would say "you got bs'd" is a bad part of the answer... but the rest is valid)

        – WernerCD
        Dec 24 '18 at 3:20






      • 7





        @Blrfl I have information that's in agreement. Perl, Java, maybe Scala. Read the last paragraph of Isotopp's SE bio for an idea of how he knows :)

        – hobbs
        Dec 25 '18 at 7:51








      15




      15





      The string 000 doesn't evaluate false in Perl, Python or JavaScript.

      – Blrfl
      Dec 23 '18 at 20:40





      The string 000 doesn't evaluate false in Perl, Python or JavaScript.

      – Blrfl
      Dec 23 '18 at 20:40




      27




      27





      Well, in JavaScript, if you compare "000" to false ("000" == false) with just 2 equals signs, it will evaluate to true.

      – Stefnotch
      Dec 23 '18 at 21:00





      Well, in JavaScript, if you compare "000" to false ("000" == false) with just 2 equals signs, it will evaluate to true.

      – Stefnotch
      Dec 23 '18 at 21:00




      8




      8





      It's more likely a case of what Mike Caron says: if(!to_number(input)) reject(). The number zero is falsy in both Javascript and PHP.

      – John Dvorak
      Dec 23 '18 at 21:03







      It's more likely a case of what Mike Caron says: if(!to_number(input)) reject(). The number zero is falsy in both Javascript and PHP.

      – John Dvorak
      Dec 23 '18 at 21:03






      9




      9





      @Blrfl I think the main point is that there are possibilities on how a modern web stack could EASILY get broke on edge cases - purposely or accidentally. There is code on the back end, middle end, front end, etc that could ALL easily break on untested edge cases. JavaScript being the easiest culprit to point fingers at - but as my example about Mr. Null (his actual name) shows, it's hard to point fingers at JS when it could be any step. (I would say "you got bs'd" is a bad part of the answer... but the rest is valid)

      – WernerCD
      Dec 24 '18 at 3:20





      @Blrfl I think the main point is that there are possibilities on how a modern web stack could EASILY get broke on edge cases - purposely or accidentally. There is code on the back end, middle end, front end, etc that could ALL easily break on untested edge cases. JavaScript being the easiest culprit to point fingers at - but as my example about Mr. Null (his actual name) shows, it's hard to point fingers at JS when it could be any step. (I would say "you got bs'd" is a bad part of the answer... but the rest is valid)

      – WernerCD
      Dec 24 '18 at 3:20




      7




      7





      @Blrfl I have information that's in agreement. Perl, Java, maybe Scala. Read the last paragraph of Isotopp's SE bio for an idea of how he knows :)

      – hobbs
      Dec 25 '18 at 7:51





      @Blrfl I have information that's in agreement. Perl, Java, maybe Scala. Read the last paragraph of Isotopp's SE bio for an idea of how he knows :)

      – hobbs
      Dec 25 '18 at 7:51











      10














      I currently have a credit card that arguably has a worse CVV number: 123



      So far it has never been denied, but from a security point of view I don't like it as I feel like it could very well be the first thing a thief would type in if somehow they had my numbers but not my card.



      From the website's point of view, IMHO it's asinine to purposely treat a valid number as invalid. (Even more so if the chances of it occurring are merely 1 in 1000.) Since it would be extremely easy for the site to attempt a very small authorization to confirm the credit card, or even let the hotel decide for themselves, I don't agree with the "preventing fake numbers" argument. That being said, a quick search yields quite a few people with the same issue on various websites over the years. So, you're not alone. :)






      share|improve this answer



















      • 32





        I now know your CVV :) Now just gotta search public credit card breaches for... uhh... "TTT"?

        – rahuldottech
        Dec 28 '18 at 11:19
















      10














      I currently have a credit card that arguably has a worse CVV number: 123



      So far it has never been denied, but from a security point of view I don't like it as I feel like it could very well be the first thing a thief would type in if somehow they had my numbers but not my card.



      From the website's point of view, IMHO it's asinine to purposely treat a valid number as invalid. (Even more so if the chances of it occurring are merely 1 in 1000.) Since it would be extremely easy for the site to attempt a very small authorization to confirm the credit card, or even let the hotel decide for themselves, I don't agree with the "preventing fake numbers" argument. That being said, a quick search yields quite a few people with the same issue on various websites over the years. So, you're not alone. :)






      share|improve this answer



















      • 32





        I now know your CVV :) Now just gotta search public credit card breaches for... uhh... "TTT"?

        – rahuldottech
        Dec 28 '18 at 11:19














      10












      10








      10







      I currently have a credit card that arguably has a worse CVV number: 123



      So far it has never been denied, but from a security point of view I don't like it as I feel like it could very well be the first thing a thief would type in if somehow they had my numbers but not my card.



      From the website's point of view, IMHO it's asinine to purposely treat a valid number as invalid. (Even more so if the chances of it occurring are merely 1 in 1000.) Since it would be extremely easy for the site to attempt a very small authorization to confirm the credit card, or even let the hotel decide for themselves, I don't agree with the "preventing fake numbers" argument. That being said, a quick search yields quite a few people with the same issue on various websites over the years. So, you're not alone. :)






      share|improve this answer













      I currently have a credit card that arguably has a worse CVV number: 123



      So far it has never been denied, but from a security point of view I don't like it as I feel like it could very well be the first thing a thief would type in if somehow they had my numbers but not my card.



      From the website's point of view, IMHO it's asinine to purposely treat a valid number as invalid. (Even more so if the chances of it occurring are merely 1 in 1000.) Since it would be extremely easy for the site to attempt a very small authorization to confirm the credit card, or even let the hotel decide for themselves, I don't agree with the "preventing fake numbers" argument. That being said, a quick search yields quite a few people with the same issue on various websites over the years. So, you're not alone. :)







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Dec 27 '18 at 16:49









      TTTTTT

      8,39041430




      8,39041430








      • 32





        I now know your CVV :) Now just gotta search public credit card breaches for... uhh... "TTT"?

        – rahuldottech
        Dec 28 '18 at 11:19














      • 32





        I now know your CVV :) Now just gotta search public credit card breaches for... uhh... "TTT"?

        – rahuldottech
        Dec 28 '18 at 11:19








      32




      32





      I now know your CVV :) Now just gotta search public credit card breaches for... uhh... "TTT"?

      – rahuldottech
      Dec 28 '18 at 11:19





      I now know your CVV :) Now just gotta search public credit card breaches for... uhh... "TTT"?

      – rahuldottech
      Dec 28 '18 at 11:19











      5














      In fairness, there are tens of thousands of hotel booking systems that booking.com have to pass information on to for them to process. I trust that booking.com can afford a developer who knows that (000) == FALSE in JavaScript... but is it worth their support time trying to diagnose the exact same bug for the hundreds of hotels who probably have this bug in their booking systems? Absolutely not.



      My guess is that this is actually a rather reasonable attempt to mitigate data processing errors that happen further down the chain, and in systems that are out of booking.com's control.



      As a card-processing merchant, they are obliged to process valid cards, so are probably breaking merchant rules here and could get in trouble with VISA (or whoever)... but i can almost see the logic.






      share|improve this answer




























        5














        In fairness, there are tens of thousands of hotel booking systems that booking.com have to pass information on to for them to process. I trust that booking.com can afford a developer who knows that (000) == FALSE in JavaScript... but is it worth their support time trying to diagnose the exact same bug for the hundreds of hotels who probably have this bug in their booking systems? Absolutely not.



        My guess is that this is actually a rather reasonable attempt to mitigate data processing errors that happen further down the chain, and in systems that are out of booking.com's control.



        As a card-processing merchant, they are obliged to process valid cards, so are probably breaking merchant rules here and could get in trouble with VISA (or whoever)... but i can almost see the logic.






        share|improve this answer


























          5












          5








          5







          In fairness, there are tens of thousands of hotel booking systems that booking.com have to pass information on to for them to process. I trust that booking.com can afford a developer who knows that (000) == FALSE in JavaScript... but is it worth their support time trying to diagnose the exact same bug for the hundreds of hotels who probably have this bug in their booking systems? Absolutely not.



          My guess is that this is actually a rather reasonable attempt to mitigate data processing errors that happen further down the chain, and in systems that are out of booking.com's control.



          As a card-processing merchant, they are obliged to process valid cards, so are probably breaking merchant rules here and could get in trouble with VISA (or whoever)... but i can almost see the logic.






          share|improve this answer













          In fairness, there are tens of thousands of hotel booking systems that booking.com have to pass information on to for them to process. I trust that booking.com can afford a developer who knows that (000) == FALSE in JavaScript... but is it worth their support time trying to diagnose the exact same bug for the hundreds of hotels who probably have this bug in their booking systems? Absolutely not.



          My guess is that this is actually a rather reasonable attempt to mitigate data processing errors that happen further down the chain, and in systems that are out of booking.com's control.



          As a card-processing merchant, they are obliged to process valid cards, so are probably breaking merchant rules here and could get in trouble with VISA (or whoever)... but i can almost see the logic.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 2 at 13:23









          hiburn8hiburn8

          31717




          31717























              3














              I have some problems with the simple "stupid bug" theory here. I have no doubt that the person you were talking to was pulling this nonsense out of thin air (as some customer services people are wont to do). 000 is perfectly valid and you're no the first person on the internet to point out having the number.



              But there's a scale here that people aren't appreciating.




              • The natural possibility of getting 000 as your CVV is 0.1%

              • Booking.com is a business that generated $8 billion in raw 2017 revenue, most on card transactions. That's about a fifty thousand medium bookings a day.

              • Booking.com must therefore encounter 000 50 times a day. To a tune of $25k lost to Booking.com and, much, much more in terms of actual bookings not passed on.


              Rejecting 0.1% of card transactions is $9m in lost revenue. In the [very much smaller] businesses I work for, booking flow analytics would flag this up the chain pretty quickly. These sorts of companies (I tangentially work in holiday booking systems), the cart experience is the most tracked part... I'm finding it very hard to believe that a company that relies on analytics would miss something as simple as a card validation issue.



              So if we assume that this cannot exist at that scale, we have to offer some suggestions that limit the scope...





              1. This is a local bug.



                Many multinationals put money through local accounts and bounce it around from there for tax purposes. It may be that Booking.com allows its local offices to edit the code on this to handle local quirks (currency, whole payment schemes that aren't global) and in doing so, allowing bugs to creep in that don't exist elsewhere.



                The possibility of this is increased because the target country is Croatia. They use the Kuna there, not the Euro. There may well be a raft of accounting differences and mechanism providers.



                That also goes some distance to explain why this has gone under the radar. 0.1% of Croatia-bound money is going to be a hell of a lot less than the global income.




              2. 000 isn't as common as 0.1%



                As JPhi1618 points out in the comments, the other scope-limiting factor is that perhaps banks don't issue 000 very often. There's no reason they shouldn't and as I've said, there is evidence online of other people with 000 cards, but that is not to say it is common.



                I have no way to verify this. Perhaps somebody with a card processing log that includes CVVs can run an analysis.




              Still, if you find issues like this, report them. Skip the customer services team because they simply don't know what's going on. Go to the CEO, or security team as they're both going to take this pretty seriously for slightly different reasons. $9m in lost revenue is a good motivator.






              share|improve this answer


























              • Just a note: I was trying to book a hotel in Croatia, which is not a Euro country, so your reasoning may be correct.

                – Vlad Nikiforov
                Jan 2 at 15:30






              • 2





                I think using your logic shows that if this 000 number was as common as expected, Booking.com would be forced to fix the issue. They aren't going to miss out on 1 out of 1000 bookings because of a very trivial thing to fix. So, I think that most credit card companies don't use 000 and the bank OP is using is an outlier.

                – JPhi1618
                Jan 2 at 16:39






              • 2





                @JPhi1618 outlier? I don't think so. A few years ago I had a VISA card from a major French bank with 000 as CVC code (now expired). Used it all its lifetime without a hitch. Never tried booking.com. My guess: they indeed lose 0.1% of their revenue. Reaching CEO of an established company is probably difficult, security team wouldn't care, current state is not a security breach.

                – Stéphane Gourichon
                Jan 2 at 22:58











              • "Reaching CEO of an established company is probably difficult". It used to be but at some point in the last 15 years it seems to have become fashionable for executives to be seen being hands-on with problems. Even if you can't talk directly, many have an internal escalation pathway. But if this is something local —as it seems it might— it might be difficult to bounce this to the right place. And ultimately the appetite for fixing 0.1% of payments through to Croatia (they use Kuna, not Euro, so possibly local code) will be somewhat lighter.

                – Oli
                Jan 3 at 9:57
















              3














              I have some problems with the simple "stupid bug" theory here. I have no doubt that the person you were talking to was pulling this nonsense out of thin air (as some customer services people are wont to do). 000 is perfectly valid and you're no the first person on the internet to point out having the number.



              But there's a scale here that people aren't appreciating.




              • The natural possibility of getting 000 as your CVV is 0.1%

              • Booking.com is a business that generated $8 billion in raw 2017 revenue, most on card transactions. That's about a fifty thousand medium bookings a day.

              • Booking.com must therefore encounter 000 50 times a day. To a tune of $25k lost to Booking.com and, much, much more in terms of actual bookings not passed on.


              Rejecting 0.1% of card transactions is $9m in lost revenue. In the [very much smaller] businesses I work for, booking flow analytics would flag this up the chain pretty quickly. These sorts of companies (I tangentially work in holiday booking systems), the cart experience is the most tracked part... I'm finding it very hard to believe that a company that relies on analytics would miss something as simple as a card validation issue.



              So if we assume that this cannot exist at that scale, we have to offer some suggestions that limit the scope...





              1. This is a local bug.



                Many multinationals put money through local accounts and bounce it around from there for tax purposes. It may be that Booking.com allows its local offices to edit the code on this to handle local quirks (currency, whole payment schemes that aren't global) and in doing so, allowing bugs to creep in that don't exist elsewhere.



                The possibility of this is increased because the target country is Croatia. They use the Kuna there, not the Euro. There may well be a raft of accounting differences and mechanism providers.



                That also goes some distance to explain why this has gone under the radar. 0.1% of Croatia-bound money is going to be a hell of a lot less than the global income.




              2. 000 isn't as common as 0.1%



                As JPhi1618 points out in the comments, the other scope-limiting factor is that perhaps banks don't issue 000 very often. There's no reason they shouldn't and as I've said, there is evidence online of other people with 000 cards, but that is not to say it is common.



                I have no way to verify this. Perhaps somebody with a card processing log that includes CVVs can run an analysis.




              Still, if you find issues like this, report them. Skip the customer services team because they simply don't know what's going on. Go to the CEO, or security team as they're both going to take this pretty seriously for slightly different reasons. $9m in lost revenue is a good motivator.






              share|improve this answer


























              • Just a note: I was trying to book a hotel in Croatia, which is not a Euro country, so your reasoning may be correct.

                – Vlad Nikiforov
                Jan 2 at 15:30






              • 2





                I think using your logic shows that if this 000 number was as common as expected, Booking.com would be forced to fix the issue. They aren't going to miss out on 1 out of 1000 bookings because of a very trivial thing to fix. So, I think that most credit card companies don't use 000 and the bank OP is using is an outlier.

                – JPhi1618
                Jan 2 at 16:39






              • 2





                @JPhi1618 outlier? I don't think so. A few years ago I had a VISA card from a major French bank with 000 as CVC code (now expired). Used it all its lifetime without a hitch. Never tried booking.com. My guess: they indeed lose 0.1% of their revenue. Reaching CEO of an established company is probably difficult, security team wouldn't care, current state is not a security breach.

                – Stéphane Gourichon
                Jan 2 at 22:58











              • "Reaching CEO of an established company is probably difficult". It used to be but at some point in the last 15 years it seems to have become fashionable for executives to be seen being hands-on with problems. Even if you can't talk directly, many have an internal escalation pathway. But if this is something local —as it seems it might— it might be difficult to bounce this to the right place. And ultimately the appetite for fixing 0.1% of payments through to Croatia (they use Kuna, not Euro, so possibly local code) will be somewhat lighter.

                – Oli
                Jan 3 at 9:57














              3












              3








              3







              I have some problems with the simple "stupid bug" theory here. I have no doubt that the person you were talking to was pulling this nonsense out of thin air (as some customer services people are wont to do). 000 is perfectly valid and you're no the first person on the internet to point out having the number.



              But there's a scale here that people aren't appreciating.




              • The natural possibility of getting 000 as your CVV is 0.1%

              • Booking.com is a business that generated $8 billion in raw 2017 revenue, most on card transactions. That's about a fifty thousand medium bookings a day.

              • Booking.com must therefore encounter 000 50 times a day. To a tune of $25k lost to Booking.com and, much, much more in terms of actual bookings not passed on.


              Rejecting 0.1% of card transactions is $9m in lost revenue. In the [very much smaller] businesses I work for, booking flow analytics would flag this up the chain pretty quickly. These sorts of companies (I tangentially work in holiday booking systems), the cart experience is the most tracked part... I'm finding it very hard to believe that a company that relies on analytics would miss something as simple as a card validation issue.



              So if we assume that this cannot exist at that scale, we have to offer some suggestions that limit the scope...





              1. This is a local bug.



                Many multinationals put money through local accounts and bounce it around from there for tax purposes. It may be that Booking.com allows its local offices to edit the code on this to handle local quirks (currency, whole payment schemes that aren't global) and in doing so, allowing bugs to creep in that don't exist elsewhere.



                The possibility of this is increased because the target country is Croatia. They use the Kuna there, not the Euro. There may well be a raft of accounting differences and mechanism providers.



                That also goes some distance to explain why this has gone under the radar. 0.1% of Croatia-bound money is going to be a hell of a lot less than the global income.




              2. 000 isn't as common as 0.1%



                As JPhi1618 points out in the comments, the other scope-limiting factor is that perhaps banks don't issue 000 very often. There's no reason they shouldn't and as I've said, there is evidence online of other people with 000 cards, but that is not to say it is common.



                I have no way to verify this. Perhaps somebody with a card processing log that includes CVVs can run an analysis.




              Still, if you find issues like this, report them. Skip the customer services team because they simply don't know what's going on. Go to the CEO, or security team as they're both going to take this pretty seriously for slightly different reasons. $9m in lost revenue is a good motivator.






              share|improve this answer















              I have some problems with the simple "stupid bug" theory here. I have no doubt that the person you were talking to was pulling this nonsense out of thin air (as some customer services people are wont to do). 000 is perfectly valid and you're no the first person on the internet to point out having the number.



              But there's a scale here that people aren't appreciating.




              • The natural possibility of getting 000 as your CVV is 0.1%

              • Booking.com is a business that generated $8 billion in raw 2017 revenue, most on card transactions. That's about a fifty thousand medium bookings a day.

              • Booking.com must therefore encounter 000 50 times a day. To a tune of $25k lost to Booking.com and, much, much more in terms of actual bookings not passed on.


              Rejecting 0.1% of card transactions is $9m in lost revenue. In the [very much smaller] businesses I work for, booking flow analytics would flag this up the chain pretty quickly. These sorts of companies (I tangentially work in holiday booking systems), the cart experience is the most tracked part... I'm finding it very hard to believe that a company that relies on analytics would miss something as simple as a card validation issue.



              So if we assume that this cannot exist at that scale, we have to offer some suggestions that limit the scope...





              1. This is a local bug.



                Many multinationals put money through local accounts and bounce it around from there for tax purposes. It may be that Booking.com allows its local offices to edit the code on this to handle local quirks (currency, whole payment schemes that aren't global) and in doing so, allowing bugs to creep in that don't exist elsewhere.



                The possibility of this is increased because the target country is Croatia. They use the Kuna there, not the Euro. There may well be a raft of accounting differences and mechanism providers.



                That also goes some distance to explain why this has gone under the radar. 0.1% of Croatia-bound money is going to be a hell of a lot less than the global income.




              2. 000 isn't as common as 0.1%



                As JPhi1618 points out in the comments, the other scope-limiting factor is that perhaps banks don't issue 000 very often. There's no reason they shouldn't and as I've said, there is evidence online of other people with 000 cards, but that is not to say it is common.



                I have no way to verify this. Perhaps somebody with a card processing log that includes CVVs can run an analysis.




              Still, if you find issues like this, report them. Skip the customer services team because they simply don't know what's going on. Go to the CEO, or security team as they're both going to take this pretty seriously for slightly different reasons. $9m in lost revenue is a good motivator.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Jan 3 at 12:37

























              answered Jan 2 at 13:00









              OliOli

              846713




              846713













              • Just a note: I was trying to book a hotel in Croatia, which is not a Euro country, so your reasoning may be correct.

                – Vlad Nikiforov
                Jan 2 at 15:30






              • 2





                I think using your logic shows that if this 000 number was as common as expected, Booking.com would be forced to fix the issue. They aren't going to miss out on 1 out of 1000 bookings because of a very trivial thing to fix. So, I think that most credit card companies don't use 000 and the bank OP is using is an outlier.

                – JPhi1618
                Jan 2 at 16:39






              • 2





                @JPhi1618 outlier? I don't think so. A few years ago I had a VISA card from a major French bank with 000 as CVC code (now expired). Used it all its lifetime without a hitch. Never tried booking.com. My guess: they indeed lose 0.1% of their revenue. Reaching CEO of an established company is probably difficult, security team wouldn't care, current state is not a security breach.

                – Stéphane Gourichon
                Jan 2 at 22:58











              • "Reaching CEO of an established company is probably difficult". It used to be but at some point in the last 15 years it seems to have become fashionable for executives to be seen being hands-on with problems. Even if you can't talk directly, many have an internal escalation pathway. But if this is something local —as it seems it might— it might be difficult to bounce this to the right place. And ultimately the appetite for fixing 0.1% of payments through to Croatia (they use Kuna, not Euro, so possibly local code) will be somewhat lighter.

                – Oli
                Jan 3 at 9:57



















              • Just a note: I was trying to book a hotel in Croatia, which is not a Euro country, so your reasoning may be correct.

                – Vlad Nikiforov
                Jan 2 at 15:30






              • 2





                I think using your logic shows that if this 000 number was as common as expected, Booking.com would be forced to fix the issue. They aren't going to miss out on 1 out of 1000 bookings because of a very trivial thing to fix. So, I think that most credit card companies don't use 000 and the bank OP is using is an outlier.

                – JPhi1618
                Jan 2 at 16:39






              • 2





                @JPhi1618 outlier? I don't think so. A few years ago I had a VISA card from a major French bank with 000 as CVC code (now expired). Used it all its lifetime without a hitch. Never tried booking.com. My guess: they indeed lose 0.1% of their revenue. Reaching CEO of an established company is probably difficult, security team wouldn't care, current state is not a security breach.

                – Stéphane Gourichon
                Jan 2 at 22:58











              • "Reaching CEO of an established company is probably difficult". It used to be but at some point in the last 15 years it seems to have become fashionable for executives to be seen being hands-on with problems. Even if you can't talk directly, many have an internal escalation pathway. But if this is something local —as it seems it might— it might be difficult to bounce this to the right place. And ultimately the appetite for fixing 0.1% of payments through to Croatia (they use Kuna, not Euro, so possibly local code) will be somewhat lighter.

                – Oli
                Jan 3 at 9:57

















              Just a note: I was trying to book a hotel in Croatia, which is not a Euro country, so your reasoning may be correct.

              – Vlad Nikiforov
              Jan 2 at 15:30





              Just a note: I was trying to book a hotel in Croatia, which is not a Euro country, so your reasoning may be correct.

              – Vlad Nikiforov
              Jan 2 at 15:30




              2




              2





              I think using your logic shows that if this 000 number was as common as expected, Booking.com would be forced to fix the issue. They aren't going to miss out on 1 out of 1000 bookings because of a very trivial thing to fix. So, I think that most credit card companies don't use 000 and the bank OP is using is an outlier.

              – JPhi1618
              Jan 2 at 16:39





              I think using your logic shows that if this 000 number was as common as expected, Booking.com would be forced to fix the issue. They aren't going to miss out on 1 out of 1000 bookings because of a very trivial thing to fix. So, I think that most credit card companies don't use 000 and the bank OP is using is an outlier.

              – JPhi1618
              Jan 2 at 16:39




              2




              2





              @JPhi1618 outlier? I don't think so. A few years ago I had a VISA card from a major French bank with 000 as CVC code (now expired). Used it all its lifetime without a hitch. Never tried booking.com. My guess: they indeed lose 0.1% of their revenue. Reaching CEO of an established company is probably difficult, security team wouldn't care, current state is not a security breach.

              – Stéphane Gourichon
              Jan 2 at 22:58





              @JPhi1618 outlier? I don't think so. A few years ago I had a VISA card from a major French bank with 000 as CVC code (now expired). Used it all its lifetime without a hitch. Never tried booking.com. My guess: they indeed lose 0.1% of their revenue. Reaching CEO of an established company is probably difficult, security team wouldn't care, current state is not a security breach.

              – Stéphane Gourichon
              Jan 2 at 22:58













              "Reaching CEO of an established company is probably difficult". It used to be but at some point in the last 15 years it seems to have become fashionable for executives to be seen being hands-on with problems. Even if you can't talk directly, many have an internal escalation pathway. But if this is something local —as it seems it might— it might be difficult to bounce this to the right place. And ultimately the appetite for fixing 0.1% of payments through to Croatia (they use Kuna, not Euro, so possibly local code) will be somewhat lighter.

              – Oli
              Jan 3 at 9:57





              "Reaching CEO of an established company is probably difficult". It used to be but at some point in the last 15 years it seems to have become fashionable for executives to be seen being hands-on with problems. Even if you can't talk directly, many have an internal escalation pathway. But if this is something local —as it seems it might— it might be difficult to bounce this to the right place. And ultimately the appetite for fixing 0.1% of payments through to Croatia (they use Kuna, not Euro, so possibly local code) will be somewhat lighter.

              – Oli
              Jan 3 at 9:57











              0














              Note that on some Credit Card software, a CVC with the magic value 000 means that a CVC was provided but has been deleted since (due to PCI constraints). That's probably what Booking is doing, and that explains why they don't accept it.



              Tough luck :/






              share|improve this answer




























                0














                Note that on some Credit Card software, a CVC with the magic value 000 means that a CVC was provided but has been deleted since (due to PCI constraints). That's probably what Booking is doing, and that explains why they don't accept it.



                Tough luck :/






                share|improve this answer


























                  0












                  0








                  0







                  Note that on some Credit Card software, a CVC with the magic value 000 means that a CVC was provided but has been deleted since (due to PCI constraints). That's probably what Booking is doing, and that explains why they don't accept it.



                  Tough luck :/






                  share|improve this answer













                  Note that on some Credit Card software, a CVC with the magic value 000 means that a CVC was provided but has been deleted since (due to PCI constraints). That's probably what Booking is doing, and that explains why they don't accept it.



                  Tough luck :/







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 3 at 9:42









                  LukLuk

                  1012




                  1012






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Information Security Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f200243%2fall-0s-zeros-in-a-bank-cards-cvc-code%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

                      Alcedinidae

                      RAC Tourist Trophy