All 0's (zeros) in a bank card's CVC code
As my bank card had expired, I got a new one, and this one turned out to be "lucky": its CVC code was 000.

For a few months I used it extensively, both online and offline, without any difficulties - until the day when I was to enter my card details on Booking.com website. I filled in the form, clicked "submit" - only to see that the page discards the value in CVC field and demands to enter it again.
I contacted support. They confirmed that CVC code "000" is not accepted, because it is considered not secure enough (not a close quote unfortunately, as the conversation was in Estonian), and they suggest me to order a new bank card where CVC code would be different from "000".
That got me puzzled. 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 infosecurity, so I came up with objections:
- First of all, 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 be just excluded from it.
- Second, I have already used this card with a number of other online services, including Amazon, whose security is out of any doubts.
- Third, I don't quite understand what does "not secure enough" mean. Are "111" or "999" secure enough? If not, how about "123" or "234"? Again, it's not something I pick by myself, it's something I'm given by a bank, and if bank thinks it's secure, then it must be treated as such.
The response was very polite yet held out little hope: "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 all the mail chain to my bank and asked for their advice. They told me they'll issue a new card for free, which solved the problem for me.
However, I still puzzled:
- Are there any official regulations/prescriptions (from Visa/MC or elsewhere) or any best practices regarding "all-zeroes" CVC/CVV codes? Especially that bit about banks allegedly using 000 as an indication of a forgery - sounds like a complete nonsense to me. I tried googling, but couldn't find anything.
- From practical point of view, how reasonable it is to decline "000" as insecure? I listed my concerns above, but maybe I'm missing something?
credit-card
New contributor
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
As my bank card had expired, I got a new one, and this one turned out to be "lucky": its CVC code was 000.

For a few months I used it extensively, both online and offline, without any difficulties - until the day when I was to enter my card details on Booking.com website. I filled in the form, clicked "submit" - only to see that the page discards the value in CVC field and demands to enter it again.
I contacted support. They confirmed that CVC code "000" is not accepted, because it is considered not secure enough (not a close quote unfortunately, as the conversation was in Estonian), and they suggest me to order a new bank card where CVC code would be different from "000".
That got me puzzled. 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 infosecurity, so I came up with objections:
- First of all, 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 be just excluded from it.
- Second, I have already used this card with a number of other online services, including Amazon, whose security is out of any doubts.
- Third, I don't quite understand what does "not secure enough" mean. Are "111" or "999" secure enough? If not, how about "123" or "234"? Again, it's not something I pick by myself, it's something I'm given by a bank, and if bank thinks it's secure, then it must be treated as such.
The response was very polite yet held out little hope: "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 all the mail chain to my bank and asked for their advice. They told me they'll issue a new card for free, which solved the problem for me.
However, I still puzzled:
- Are there any official regulations/prescriptions (from Visa/MC or elsewhere) or any best practices regarding "all-zeroes" CVC/CVV codes? Especially that bit about banks allegedly using 000 as an indication of a forgery - sounds like a complete nonsense to me. I tried googling, but couldn't find anything.
- From practical point of view, how reasonable it is to decline "000" as insecure? I listed my concerns above, but maybe I'm missing something?
credit-card
New contributor
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Your reasoning is entirely correct, that's the long and short of it. Looks likebooking.comemploys some moron managers (I bet this wasn't an engineering decision).
– Luc
1 hour ago
add a comment |
As my bank card had expired, I got a new one, and this one turned out to be "lucky": its CVC code was 000.

For a few months I used it extensively, both online and offline, without any difficulties - until the day when I was to enter my card details on Booking.com website. I filled in the form, clicked "submit" - only to see that the page discards the value in CVC field and demands to enter it again.
I contacted support. They confirmed that CVC code "000" is not accepted, because it is considered not secure enough (not a close quote unfortunately, as the conversation was in Estonian), and they suggest me to order a new bank card where CVC code would be different from "000".
That got me puzzled. 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 infosecurity, so I came up with objections:
- First of all, 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 be just excluded from it.
- Second, I have already used this card with a number of other online services, including Amazon, whose security is out of any doubts.
- Third, I don't quite understand what does "not secure enough" mean. Are "111" or "999" secure enough? If not, how about "123" or "234"? Again, it's not something I pick by myself, it's something I'm given by a bank, and if bank thinks it's secure, then it must be treated as such.
The response was very polite yet held out little hope: "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 all the mail chain to my bank and asked for their advice. They told me they'll issue a new card for free, which solved the problem for me.
However, I still puzzled:
- Are there any official regulations/prescriptions (from Visa/MC or elsewhere) or any best practices regarding "all-zeroes" CVC/CVV codes? Especially that bit about banks allegedly using 000 as an indication of a forgery - sounds like a complete nonsense to me. I tried googling, but couldn't find anything.
- From practical point of view, how reasonable it is to decline "000" as insecure? I listed my concerns above, but maybe I'm missing something?
credit-card
New contributor
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
As my bank card had expired, I got a new one, and this one turned out to be "lucky": its CVC code was 000.

For a few months I used it extensively, both online and offline, without any difficulties - until the day when I was to enter my card details on Booking.com website. I filled in the form, clicked "submit" - only to see that the page discards the value in CVC field and demands to enter it again.
I contacted support. They confirmed that CVC code "000" is not accepted, because it is considered not secure enough (not a close quote unfortunately, as the conversation was in Estonian), and they suggest me to order a new bank card where CVC code would be different from "000".
That got me puzzled. 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 infosecurity, so I came up with objections:
- First of all, 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 be just excluded from it.
- Second, I have already used this card with a number of other online services, including Amazon, whose security is out of any doubts.
- Third, I don't quite understand what does "not secure enough" mean. Are "111" or "999" secure enough? If not, how about "123" or "234"? Again, it's not something I pick by myself, it's something I'm given by a bank, and if bank thinks it's secure, then it must be treated as such.
The response was very polite yet held out little hope: "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 all the mail chain to my bank and asked for their advice. They told me they'll issue a new card for free, which solved the problem for me.
However, I still puzzled:
- Are there any official regulations/prescriptions (from Visa/MC or elsewhere) or any best practices regarding "all-zeroes" CVC/CVV codes? Especially that bit about banks allegedly using 000 as an indication of a forgery - sounds like a complete nonsense to me. I tried googling, but couldn't find anything.
- From practical point of view, how reasonable it is to decline "000" as insecure? I listed my concerns above, but maybe I'm missing something?
credit-card
credit-card
New contributor
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 2 hours ago
New contributor
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
Vlad Nikiforov
1363
1363
New contributor
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Vlad Nikiforov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Your reasoning is entirely correct, that's the long and short of it. Looks likebooking.comemploys some moron managers (I bet this wasn't an engineering decision).
– Luc
1 hour ago
add a comment |
1
Your reasoning is entirely correct, that's the long and short of it. Looks likebooking.comemploys some moron managers (I bet this wasn't an engineering decision).
– Luc
1 hour ago
1
1
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
1 hour ago
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
1 hour ago
add a comment |
1 Answer
1
active
oldest
votes
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.
add a comment |
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
});
}
});
Vlad Nikiforov is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
add a comment |
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.
add a comment |
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.
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.
answered 2 hours ago
Alexander O'Mara
6,61542633
6,61542633
add a comment |
add a comment |
Vlad Nikiforov is a new contributor. Be nice, and check out our Code of Conduct.
Vlad Nikiforov is a new contributor. Be nice, and check out our Code of Conduct.
Vlad Nikiforov is a new contributor. Be nice, and check out our Code of Conduct.
Vlad Nikiforov is a new contributor. Be nice, and check out our Code of Conduct.
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
1
Your reasoning is entirely correct, that's the long and short of it. Looks like
booking.comemploys some moron managers (I bet this wasn't an engineering decision).– Luc
1 hour ago