238

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.

Update 2: After several months of trying to contact Booking.com's support I officially give up. I haven't gone any further than a countless number of support tickets that were not even confirmed, not to mention being reacted on, and a couple of phone calls where I explained the situation and got nothing but a canned email "we are trying very hard to solve your problem". Bottomline: Booking.com's support doesn't work - unless your problem is very standard, it won't be solved nor escalated to higher management.

The bug still exists. I'm now assured that it is nothing but a software bug, because CVC "000" is perfectly accepted when you add a new card, but it doesn't work when you are trying to update an expired (or otherwise invalid card). Here's the repro steps:

  1. Create a new booking that requires immediate payment.
  2. Enter an invalid card (expired or blocked).
  3. When the system sends a notification that the card can't be processed, select "update card details" and enter details of a valid card with CVC code 000.

Expected result: the card data gets accepted for further processing.

Actual result: the entered CVC code gets discarded and the dialog window complains that CVC code is not entered.

Vlad Nikiforov
  • 2,023
  • 2
  • 6
  • 9
  • 100
    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
  • 134
    "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 00:46
  • 6
    @MikeCaron While a bank wouldn't make a forged card they might have reason to make a deliberately invalid one, just like movies need deliberately invalid phone numbers. – Loren Pechtel Dec 23 '18 at 05:13
  • 2
    That's fine and wholly irrelevant to the quote I was responding to. Sample cards (like you suggest) are not the same as forgeries. The person claiming "the bank did it" is suggesting that somehow the bank is able to make the card have 000 for its CVV, which would be impossible if the bank did not also produce the card. Perhaps they are forging other banks' cards... – Mike Caron Dec 23 '18 at 05:18
  • 7
    @Jérôme, I could (the card has been deactivated upon re-issue), yet I'm curious what exactly are you expecting to see on the other side :) – Vlad Nikiforov Dec 23 '18 at 11:20
  • 27
    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
  • 1
    For what it's worth, "a way banks indicate that the card is a forgery" *could* be a garbled/ill-worded form of trying to express that it's how banks *recognize some* forgeries (that are lazy enough not to bother with producing a less special looking number). – O. R. Mapper Dec 23 '18 at 21:50
  • 7
    Hate to say it but @Harper's answer is likely the correct one. Occam's Razor should apply here; Zoey and Alexander's answers are plausible, but ultimately they're just grafting contrived logic onto a simple software bug. This is exacerbated by the fact that no one you could ever speak to on a customer service line would know anything about the system's back-end design, nor could they even hope to reach someone on the web development team even if they wanted to. – Wes Sayeed Dec 24 '18 at 08:15
  • 6
    minor nitpick : the fact that CVC is calculated with a deterministic algorithm isn't enough to show that all values are possible and equally probable. – Eric Duminil Dec 24 '18 at 09:40
  • 2
    @WesSayeed, I agree that this is probably a bug, turned into a feature by stubborn and lazy management. That's why I'm going to give it another try and insist on getting this fixed. – Vlad Nikiforov Dec 24 '18 at 09:47
  • 25
    @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
  • 3
    *Amazon, whose security is out of any doubts* - wut? And you work in this sector? – Mazura Dec 24 '18 at 22:21
  • 2
    @Mazura, I probably should have been more specific - I meant AWS. I have no experience with the rest of Amazon, but AWS never spawned any doubts. – Vlad Nikiforov Dec 25 '18 at 08:57
  • 4
    CVC is considered confidential, similar with PIN. Since you have shared it here, please be sure to get a new one. – Thariq Nugrohotomo Dec 26 '18 at 02:22
  • 2
    Some new cards have a dynamic CVV (DCV), changing every half-hour or so... If you have such a card and 000 shows up, just wait for the next CVV to show up. – Olivier Grégoire Dec 27 '18 at 11:17
  • 26
    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
  • 2
    @Luc Or worse, this was the decision of a lazy/inept engineer. – TylerH Dec 27 '18 at 20:12
  • 5
    Does this mean booking.com is rejecting 1 out of every 1000 valid credit cards — assuming all CVCs are equally likely? – Colin 't Hart Dec 27 '18 at 21:30
  • 4
    Assuming Amazon security is not to be doubted is a flaw, Amazon handle risks by using insurances and the fact that they can accept fraud to some extend as long as most customer are happy. Amazon even uses non ACID DB to handle stok as they can deal with eventual stock mistakes by refunding or offering something else to its customer. – Kiwy Dec 28 '18 at 11:50
  • 14
    When designing the Enigma machines, the Germans prevented it from using any permutations in which a letter was mapped to itself, because that didn't *look* secure. This gave Allied cryptographers an easy way to quickly rule out large numbers of candidate keys. If the permutations that *looked* insecure had been permitted, it's quite possible that Enigma would never have been broken. The only thing prohibiting 000 does is give attackers a smaller set to guess from. – Ray Dec 28 '18 at 20:57
  • 2
    @MrWhite Updated the post to specifically point to AWS, not just Amazon. Sorry for not making this clear in the first place. – Vlad Nikiforov Dec 30 '18 at 23:50
  • 2
    @Colin'tHart - it's likely booking.com rejects even more than that, because hotel bookings is a very high fraud area and their fraud detection probably has a non-negligible number of false positives. But it's also possible some credit card issuers purposefully do not issue cards with 000 as the CVV, so it may not be the case that 1 in 1000 cards has 000 as the CVV. – thomasrutter Jan 01 '19 at 23:59
  • 3
    @Luc I'd be absolutely shocked if this wasn't a poor engineering decision/bug that a manager later misunderstood or lied about. There are undoubtedly many sites that treat the input as an integer instead of a string, viewing `000` as `0`, and would treat `0` as invalid or as a default representing nothing being entered. – Matthew Read Jan 02 '19 at 19:14
  • I just googled this as I'm on the merchant end of this situation. Our payment processor that handles transactions automatically declines the transaction as an invalid security code, its a major payment processor. I've argued the same thing, its code given to the card that can be verified, but its an auto rejection. – Jessie Jul 19 '19 at 01:29

7 Answers7

188

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.

yoozer8
  • 810
  • 2
  • 7
  • 17
Zoey
  • 1,688
  • 1
  • 8
  • 8
  • 97
    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 03:20
  • 8
    @aidanh010 smaller hotels often don't bother with it, either because they aren't familiar with the process or they assume it's too much effort for little benefit – Zoey Dec 23 '18 at 03:46
  • 84
    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
  • 13
    Actually it seems optional: https://partnerhelp.booking.com/hc/en-gb/articles/115003200353?utm_source=checkin&utm_medium=link&utm_content=preauthorisation – eckes Dec 23 '18 at 12:24
  • 49
    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
  • 28
    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
  • 3
    @gnasher729: Well, they didn't know. Now, after this answer has been posted, on the other hand ... ;) – O. R. Mapper Dec 23 '18 at 21:48
  • 1
    @Lucero That procedure is standard for travel. If you book a flight, the airline is the one who charges your card, not the travel site, you're going to a travel "agent" not "reseller". Hotels, cruises, rental cars are the same. The only exception is when you're purchasing a heavily discounted opaque fare (Priceline, Hotwire, packages, etc.). – user71659 Dec 23 '18 at 22:30
  • 109
    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 01:49
  • 7
    This makes me wonder if OP could have entered any other value as CVV and successfully get the booking. If yes, it would have to be fixed later with the hotel (“_oh sorry, it was a typo_”). If not, it means there is a stronger check afterwards, making the "000" check irrelevant… Well, except maybe if the stronger check is a paying service, which is also possible. They would most likely not communicate about it if it was the case, I guess. – Didier L Dec 26 '18 at 00:23
  • 1
    @gnasher729: I don't think the 25% of those using fake credit card numbers to book hotels without showing up are scammers. – user541686 Dec 26 '18 at 11:39
  • 5
    Why exactly would scammers book hotels and not show up? Is this a way to see if the credit card is still valid? Seems silly if it winds up not getting charged anyways b/c they didn't show up. – irritable_phd_syndrome Dec 27 '18 at 10:32
  • I'm curious if places avoid doing the $1 charge system, because it costs them money. A credit card provider usually charges at least 3% to process the card transaction. If they did a charge of $1, and refund it, they may only receive 97c and then return $1, losing 3c. This could cost them a lot of money in the long run if fake cards are used (but are given an allocation of $1 to look valid). – Richard Duerr Dec 27 '18 at 14:27
  • 2
    @RichardDuerr it depends how much you lost on a fake booking I guess? I would guess they stand to lose more than 3c per fake booking – Patrice Dec 27 '18 at 14:30
  • @Patrice Yup, I would argue they did (lost of labor, possible printing, time, etc). I just simplified it to make it easier to grok. – Richard Duerr Dec 27 '18 at 14:39
  • 9
    This answer hinges on assumption that 000 translates to a fake booking. But it provides no reasoning on how those two are connected. I read it as "Why are you wearing a green sweater? Because mom is sleeping." It needs establishing some link, like "all my other sweaters make noises when I move" – Agent_L Dec 27 '18 at 16:12
  • 7
    @Lucero technically, if booking.com doesn't charge credit cards themselves at all then they wouldn't have to comply with PCI DSS, as it's a private standard. But it's definitely absurd to store a CCV and transmit it to a third party--I certainly would never use such a service. If nobody can be bothered to deal with credit cards, the least they could do is use Stripe and never have to touch the data – aidanh010 Dec 28 '18 at 05:45
  • 2
    @aidanh010 Well, I guess because, surprisingly enough, credit and debit cards don't work the same all over the world. Recently I bought something off a US merchant with my Argentina debit card. Then the order was canceled and the charge wasn't removed. The merchant told me they didn't charge my card, but only put an authorization on it. My banks told me debit cards in Argentina don't do authorizations, only charges. Now my money is in a limbo and 2 months later I'm still not able to get it back. – hjf Dec 28 '18 at 13:54
  • @gnasher729 I suspect the problem here isn't smart, motivated scammers, if 90% of the entries with fake details don't show up. 000 is probably just the person being lazy. – Riking Dec 30 '18 at 16:56
  • 4
    @RichardDuerr Hotels wouldn't normally use a charge to "check" a card; they'd place an [authorization hold](https://en.wikipedia.org/wiki/Authorization_hold) for the base cost of the stay, ensuring that the card can be charged for at least that amount at the end of the stay. I have no idea why any hotel would not do this simple and common procedure. – cjs Jan 01 '19 at 06:04
149

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.

michaelb958--GoFundMonica
  • 135
  • 6
Alexander O'Mara
  • 8,774
  • 6
  • 34
  • 38
  • 173
    `var cvv = parseInt(form.cvv); if(!cvv) markInvalid()` – Mike Caron Dec 23 '18 at 00:47
  • 13
    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 03:18
  • 3
    @MikeCaron Sadly, I could see even myself making this mistake and not catching it until a support call came in... but is that the actual JS code from Booking.com? – Chris Cirefice Dec 23 '18 at 10:23
  • 2
    Another common occurrence is too short input fields for things like email addresses, postal addresses, passwords. An email address can be up to 256 characters but I have seen multiple sites using a 30 character field. And 20 character password fields are not uncommon. – kasperd Dec 23 '18 at 11:06
  • 36
    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
  • 2
    I remember some apps had significant problems running on MacOS 10.4.10 because their code required say 10.4.2 and an incorrect check told that 10.4.10 was earlier than 10.4.2. – gnasher729 Dec 23 '18 at 18:15
  • 28
    @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
  • 6
    @FelipePereira Every time I come across a website that doesn't accept email aliases, I wish there was a "punch the programmer who wrote this in the face" button. – Ian Kemp Dec 24 '18 at 13:58
  • 4
    @MikeCaron If that's the actual JS then I would be highly tempted to try circumventing it in the browser and seeing if the back end matched the same validation. (I have successfully done this in different but similar circumstances...sometimes I just want to send in a patch file.......) – user3067860 Dec 24 '18 at 18:28
  • 13
    My four-letter TLD causes email validation problems on some particularly stupid websites. – Lightness Races in Orbit Dec 25 '18 at 00:03
  • 5
    I keep thinking of Enigma in WWII. The Enigma machine could not encode a letter as itself. The machine wiring prohibited this. What first sounds like common sense is actually a vulnerability that was exploited to crack the algorithms used. https://youtu.be/V4V2bpZlqx8 – Bacon Bits Dec 26 '18 at 08:48
  • 2
    Dude, with the name like yours SQL injection is in your future :) But seriously, it's just a lazy coding, that's it. First comment sums it up quite nicely. – c00000fd Dec 27 '18 at 06:49
  • 2
    @c00000fd *"SQL injection is in your future"* And even more in my past. :p (Fortunately, things seem to be improving, as I break less stuff that I used to) – Alexander O'Mara Dec 27 '18 at 06:51
  • 1
    @EricDuminil AFAIK, by "too many programs" they simply meant "Java". – user253751 Dec 27 '18 at 11:46
  • @ChrisCirefice I was a joke I wrote, but I cannot rule out that it might also be representative of the actual code – Mike Caron Dec 28 '18 at 04:18
  • 2
    The "+" email addressing as a valid but fequently considered non-valid email address is one i love. i once had a company change their validation after i had already signed up with a xxxx+something@gmail.com address. They kept sending me messages that I didn't need, but I couldn't log in to turn it off. And their response when I asked them to help when I couldn't log in was "just sign up again". When I finally threatened to sue them for sending SPAM (since I couldn't opt out), they magically found a way to help – psubsee2003 Dec 31 '18 at 00:41
  • 1
    @EricDuminil but I liked to believe there was no win 9 'cause 7 ate 9 >:( You party pooper. – Mohd Abdul Mujib Jan 02 '19 at 17:22
94

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.

Harper - Reinstate Monica
  • 3,101
  • 10
  • 17
  • 16
    The string `000` doesn't evaluate false in Perl, Python or JavaScript. – Blrfl Dec 23 '18 at 20:40
  • 29
    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
  • 4
    @Birfl without knowing which language is used, this could absolutely be a valid answer - especially considering JavaScript is wonky like this. Look at someone who's last name is literally "Null" https://www.wired.com/2015/11/null/ – WernerCD Dec 23 '18 at 22:32
  • 1
    @Blrfl sure, if you force-type it to be a string. But if you only *aim* to do that, but err in your understanding of how the language parses... How about the *scalar* '000'? – Harper - Reinstate Monica Dec 24 '18 at 00:22
  • 1
    @WernerCD Sure, if you happen to be using a language that behaves that way. This answer draws conclusions based on facts not in evidence and makes a generalization about dynamically-typed languages that doesn't hold true for all of them. I think I've just talked myself into a downvote. – Blrfl Dec 24 '18 at 03:15
  • 11
    @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 03:20
  • @WernerCD addressed. The copany's excuse is simply not credible. As witnessed by what *is* in evidence: OP's success at using the CVC just about everywhere else. I simply disagree with Birfl's literalism that everything in OP must be treated as absolute fact. I have no reason to doubt. OP, but the company is simply wrong. – Harper - Reinstate Monica Dec 24 '18 at 03:45
  • 2
    @Stefnotch thanks for the example. I always find it really funny how JS is broken beyond repair. And then I get sad when I realize how widespread this language is. – Eric Duminil Dec 24 '18 at 12:37
  • 4
    @blrfl Booking would have been using Perl (or Java). – Isotopp Dec 24 '18 at 12:53
  • @Isotopp You know that how, exactly? – Blrfl Dec 24 '18 at 13:01
  • @Harper I think we are talking past each other - there's no doubt the company is "wrong". 000 is neither "insecure" or "invalid" - its not a pin to choose, it's a technically valid CVV. I think we differ in that a "help desk" person isn't going to know why a complicated stack of software is refusing the transaction ("000" == false). I don't think it's unexpected that help desk uses mumbo jumbo (000 is OBVIOUSLY insecure - just like a PIN you choose) to explain away errors no one in chain understands. Two sides of the coin - TECHNICALLY reason why it's failing and bad explanations why. – WernerCD Dec 24 '18 at 14:02
  • 8
    @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 07:51
  • It’s possible they use 000 as a “flag” value for unassigned CVV numbers, instead of having a separate “null” value that you might see in a typical database. I’ve seen companies with database “architects” that mindlessly enforce rules like _no null values in the database_; once given the requirements, they’d define the CVV column as “CHAR(3),NONULL”, which led to poorly written workarounds like this. – John Deters Dec 30 '18 at 07:01
  • @JohnDeters Why would it be mindless to accept credit card information into the database *with* a CVV that is null? If the developers are writing workarounds for valid designs then its their fault for pumping out poor work. I've seen a lot of that kind of mindless work, for sure. – ian Dec 30 '18 at 16:48
  • 1
    @Iain , because sometimes the information isn’t available. Not all input comes through the same validation channels. A faxed piece of paper missing some bits of data still needs to be processed. (Especially true when talking about PCI data that is prohibited from being stored anyway; no rational security minded customer should provide it on paper.) – John Deters Dec 30 '18 at 16:54
  • @JohnDeters I'm happy to split the difference and provide a "PendingCreditCards" table :) – ian Dec 30 '18 at 17:12
11

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

TTT
  • 9,122
  • 4
  • 19
  • 31
  • 40
    I now know your CVV :) Now just gotta search public credit card breaches for... uhh... "_TTT_"? – undo 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.

hiburn8
  • 441
  • 2
  • 11
4

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.

Oli
  • 1,121
  • 9
  • 13
  • 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 02 '19 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 02 '19 at 16:39
  • 3
    @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 02 '19 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 03 '19 at 09: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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Luk
  • 101
  • 2