银行卡 CVC 代码中的全 0(零)

信息安全 信用卡
2021-08-22 22:16:55

我的银行卡最近过期了。我得到了一个新的,这个结果是“幸运的”:它的 CVC 代码是000

CVC 代码为 000

几个月来,我在网上和线下都广泛使用了它,没有任何困难——直到我在 Booking.com 上输入我的卡详细信息的那一天。我填写了表格,点击了“提交”——只是看到页面丢弃了 CVC 字段中的值并要求我再次输入。

我联系了支持。他们确认 CVC 代码“000”是不可接受的,因为它被认为不够安全(不幸的是,不是准确的报价,因为对话是用爱沙尼亚语进行的),他们建议我订购一张 CVC 代码不同的新银行卡从“000”。

这让我很困惑。作为一名前测试人员,我已经习惯了我认为我报告了一个错误然后我被告知它实际上是一个特性的情况,但这一次它有点违反常识。我目前的工作也与信息安全有关,我可以想到他们的说法没有意义的三个原因:

  1. CVC 不仅仅是一个随机数,它有一定的算法生成。反过来,这意味着所有值都是同样可能的,并且不能将某些特定数字排除在外。
  2. 我已经将这张卡与许多其他在线服务一起使用,包括亚马逊网络服务,其安全性是毫无疑问的。
  3. 我不太明白“不够安全”是什么意思。“111”或“999”是否足够安全?如果不是,“123”或“234”怎么样?再说一次,这不是我自己挑的东西,这是银行给我的东西,如果银行认为它是安全的,那么它必须被这样对待。

他们的回答很有礼貌,但不是很有帮助:“我们完全理解您的沮丧,对于给您带来的不便,我们深表歉意。我们将您的理由交给了我们的管理层——他们回应说 000 被认为是无效的,这也是银行的一种方式表明该卡是伪造的”。

我将邮件链转发给我的银行并征求他们的意见。他们告诉我他们会免费发行一张新卡,这为我解决了问题。

但是,我仍然想知道:

  1. 是否有任何官方法规/规定(来自 Visa/MC 或其他地方)或有关“全零”CVC/CVV 代码的任何最佳实践?尤其是关于银行据称使用 000 作为伪造标志的那一点——对我来说听起来完全是胡说八道。我尝试谷歌搜索,但找不到任何东西。
  2. 从实践的角度来看,拒绝“000”为不安全的合理性有多大?我在上面列出了我的担忧,但也许我遗漏了什么?

更新:关于接受哪个答案的艰难选择......我非常喜欢Alexander O'Mara 的答案- 它详细且切中要害。哈珀回答的最新修订版似乎也很合理。然而,我最终决定接受佐伊的回答——这似乎是最相关的,因为它除了其他一切之外,还揭示了酒店业务的内部结构。

感谢大家的回答和评论!我现在要做的是再次联系 Booking.com 支持并坚持修复此问题。会让你知道结果。

更新 2:在尝试联系 Booking.com 的支持几个月后,我正式放弃了。我只收到了无数的支持票,这些票甚至都没有得到确认,更不用说被回应了,还有几个电话我解释了情况,只收到一封罐头电子邮件“我们正在尝试非常很难解决你的问题”。底线:Booking.com 的支持不起作用 - 除非您的问题非常标准,否则它不会得到解决,也不会升级到更高的管理层。

该错误仍然存​​在。我现在确信这只是一个软件错误,因为当您添加新卡时完全接受 CVC“000”,但当您尝试更新过期(或其他无效卡)时它不起作用。这是复制步骤:

  1. 创建需要立即付款的新预订。
  2. 输入无效卡(已过期或被冻结)。
  3. 当系统提示该卡无法处理时,选择“更新卡详细信息”并输入CVC代码为000的有效卡的详细信息。

预期结果:卡数据被接受以进行进一步处理。

实际结果:输入的 CVC 代码被丢弃,对话窗口提示未输入 CVC 代码。

4个回答

Alexander O'Mara 提供了正确答案,但在使用 booking.com 的酒店工作过,我相信我可以提供有关 CVV 被拒绝原因的更多信息。

我工作的酒店每天都会收到大约 50 份预订,其中四分之一的预订使用了虚假的信用卡详细信息,大约 90% 的使用虚假信用卡详细信息的人不会出现。

这导致在分配房间时有很多猜测,我们经常会尝试根据他们的信用卡详细信息来猜测这个人是否会出现,有时还会考虑他们的姓名、位置、他们将入住多少天,等。我们也会尝试在前一天打电话确认预订,以便这些虚假预订对业务的影响最小。

阻止 CVV 000 只是 booking.com 减少虚假预订数量的懒惰尝试。其他一些 CVV 也被阻止。

Booking.com之所以屏蔽CVV,而其他网站不屏蔽,是因为其他网站一般会尝试立即从信用卡中扣款,而booking.com只将信息转发给在抵达当天从信用卡中扣款的酒店。

我能想到的拒绝此类 CVV 的唯一弱论点是,如果有人试图暴力破解您的 3 位数代码,他们可能会000第一个开始(但他们也会拒绝001吗?)。

从实践的角度来看,拒绝“000”为不安全的合理性如何?

这并不合理。您可以使用提供的 CVC/CVV 代码对卡进行收费,也可以不收费。没有充分的理由拒绝此代码,因为它是有效的,并且在您实际尝试对其收费之前,您无法确定信用卡代码是否有效。

可悲的是,设计不佳的输入验证太常见了。一些开发人员倾向于在不检查规范的情况下假设某些值是无效的,或者没有正确地对他们的输入验证进行单元测试。

一些例子包括:

  • IP 地址1.1.1.1
  • 如果仅检查字符串中的第一个字符,则版本检查错误,例如“10”<“9”
  • 带有非字母字符的名字(比如我名字中的撇号)

客户服务人员甚至在没有咨询开发人员的情况下,就会以“这不是错误,这是一项功能”之类的方式来回应您的错误报告,这种情况并不少见。

这是对公司索赔的框架挑战。000-999 范围内的随机数比 001-998 更安全,拒绝值会削弱它

这是一个软件错误。他们不能承认。

仅举一个例子:比如说,在堆栈的某个地方,他们使用一种具有无类型变量的语言(即,同一个变量可以保存 123.45、“晚饭”、0 字符串、“未定义”标记等)。写这个是很平常的:

if ($CVC) # is CVC field present?

在无类型语言中,如程序员所期望的那样,空白字符串的计算结果为 0(假),但 000 也是如此!有更好的方法来做到这一点。

在这种情况下,我们知道问题不在于您使用的面向公众的 Web UI,而在于你们共享的后端平台。代理应该在票务系统中打开一个错误。

那么他们为什么要声称他们所说的呢?因为正常的企业是非常不愿意承认这种结构性错误,让他们看起来无能的。但是他们也不能用“我不知道”来让你离开,因为这具有相同的效果。所以他们现在需要对你说一些他们觉得可以卖的东西。

显然这是错误的;正如与您有业务往来的所有其他人所证明的那样,他们对此没有任何问题。但是你自己试试;尝试竞争的预订平台,看看情况如何。

我目前有一张信用卡的 CVV 号码可能更差:123

到目前为止,它从未被拒绝过,但从安全的角度来看,我不喜欢它,因为我觉得如果他们有我的号码而不是我的卡,这很可能是小偷输入的第一件事。

从网站的角度来看,恕我直言,故意将有效号码视为无效号码是愚蠢的。(如果它发生的可能性仅为千分之一,则更是如此。)由于该网站尝试非常小的授权来确认信用卡,甚至让酒店自己决定是非常容易的,所以我不这样做。不同意“防止假号码”的说法。话虽如此,多年来,快速搜索会在各种网站上产生相当多的人遇到相同问题。所以,你并不孤单。:)