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



我花了几个月的时间在网上广泛使用它并可以离线使用,没有任何困难-直到我在Booking.com输入我的银行卡详细信息之日。我填写了表单,单击“提交”-只是看到页面丢弃了CVC字段中的值,并要求我再次输入。

我联系了支持部门。他们确认了CVC代码“ 000”是不可接受的,因为它被认为不够安全(不幸的是,由于谈话是在爱沙尼亚语中,因此并没有确切的引号),并且他们建议我订购一张新的银行卡,其中CVC代码将有所不同来自“ 000”。

我很困惑。作为一名前测试人员,我已经习惯了一些情况,在这种情况下,我认为我正在报告一个错误,然后我被告知它实际上是一项功能,但这次却有些违反常识。我当前的工作也与信息安全有关,我可以想到三个理由,它们的主张不合理:


CVC不仅是随机数,还存在一种确定算法生成它。反过来,这意味着所有值都是同等可能的,并且不能仅仅排除某些数值。
我已经将此卡与许多其他在线服务一起使用,包括Amazon Web Services,其安全性毫无疑问。
我不太理解“不够安全”的含义。 “ 111”或“ 999”是否足够安全?如果不是,那么“ 123”或“ 234”如何?再说一次,这不是我自己选择的东西,而是银行给我的东西,如果银行认为它是安全的,那么就必须这样对待。

他们的回应非常客气,但没有帮助:“我们完全理解您的无奈,对于给您带来的不便,我们深表歉意。我们将您的推理移交给了我们的管理层-他们回应说000被认为是无效的,这也是银行的一种方式表示该卡是伪造的。”

我将邮件链转发给了我的银行,并要求他们提供建议。他们告诉我他们会免费发行一张新卡,从而为我解决了问题。

但是,我仍然想知道:


法规/规定(来自Visa / MC或其他机构)或有关“全零” CVC / CVV代码的最佳做法?特别是有关银行据称使用000来表示伪造的那句话-听起来对我完全是胡说八道。我尝试使用Google搜索,但找不到任何内容。
从实践的角度来看,将“ 000”拒绝为不安全有多合理?我在上面列出了我的担忧,但是也许我遗漏了一些东西?

更新:很难选择要接受的答案...我非常喜欢Alexander O'Mara的答案-详细且到这一点。 Harper答案的最新版本似乎也很合理。但我最终还是决定接受Zoey的回答-似乎最相关,因为它除了其他方面,还为酒店业务的内部结构提供了一些启示。

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

更新2:在尝试联系Booking.com的支持几个月后,我正式放弃了。除了没有得到证实的无数支持票外,我什么也没有做,更不用说被回应了,还有几个电话,我解释了这种情况,除了罐装电子邮件外什么也没收到,“我们正在努力很难解决您的问题”。底线:Booking.com的支持不起作用-除非您的问题非常标准,否则它将无法解决,也不会升级为更高的管理。

该错误仍然存​​在。我现在可以放心,它不过是软件错误,因为添加新卡时完全可以接受CVC“ 000”,但是当您尝试更新过期的卡(或无效的卡)时,它不起作用。以下是复制步骤:


创建需要立即付款的新预订。
输入无效的卡(已过期或已冻结)。
系统发送通知时不能处理该卡,请选择“更新卡详细信息”,然后输入CVC代码为000的有效卡的详细信息。

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

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

评论

您的推理是完全正确的,这就是它的长短。看起来booking.com雇用了一些白痴经理(我敢打赌这不是工程决策)。

“他们回答说000被认为是无效的,这也是银行表明该卡是伪造的一种方式”。我想知道为什么银行会生产一张上面带有000的伪造卡

出于种种猜测,booking.com出现了一个错误,即代码无法分辨输入000的人与将该字段留空的人之间的区别。他们没有正确地解决它,而是拒绝000作为CVC。应该解雇程序员,但是您没有这个选择。如我所见,您可以在酒店使用其他供应商,也可以致电您的银行并声明卡已丢失/被盗。他们将发行带有新号码的新卡。运气好的话,CVC就不会是000

@VladNikiforov如果他们不愿意解决此问题,只需在适当的网站(例如medium.com)上编写此故事,然后在适当的社交媒体上进行共享(例如/ r / reddit上的编程)即可。由于他们的无能而获得的可耻的booking.com数量将迫使他们对其进行修复。

与您的信用卡网络(Visa / Mastercard)联系,并投诉该网站恶意拒绝接受您的有效卡。 Visa的论点足以使他们修改其代码。该网站根据某些合同显示徽标,无端拒绝可能违反了该徽标。

#1 楼

亚历山大·奥玛拉(Alexander O'Mara)提供了正确的答案,但是曾经在使用booking.com的酒店工作过,我相信我可以提供其他有关CVV被拒绝的原因的信息。

我每天工作的酒店会收到约50笔预订,其中四分之一的预订将使用伪造的信用卡详细信息,并且大约90%的使用伪造的信用卡详细信息的人不会出现。

这导致在分配房间时会产生很多猜测,我们通常会尝试仅根据他们的信用卡详细信息猜测该人是否会出现,并且有时还会考虑姓名,位置,他们将停留多少天,等等。
我们也将尝试在前一天致电确认预订,以使这些虚假预订对业务造成的干扰最小。

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

booking.com阻止CVV和其他网站没有阻止的原因是,其他网站通常会尝试立即从信用卡中收取费用,而booking.com仅转发信息抵达当天使用信用卡付款的酒店。

评论


为什么酒店实际上不预先授权信用卡?他们只需支付1美元(用于免费试用验证),就可以立即停止此问题-但这不会造成将任何低限制或借记卡最大化的副作用。

–aidanh010
18/12/23在3:20

您是说像booking.com这样的成功在线平台无法为付费客户(也就是酒店)进行预身份验证吗?

–eckes
18/12/23在12:13

但是,阅读此评论后,为什么骗子会给您000作为CVV?由于未选中“ 000看起来可疑”,所以为什么不使用472作为CVV或其他999个可能的数字之一?

– gnasher729
18/12/23在18:17

关于booking.com处理信用卡数据的这种解释给我提出了一个问题,即他们的过程是否确实符合PCI DSS或违反了PCI DSS。有人可能会争辩说他们不做授权,因此没有违反(“授权后,敏感身份验证数据不得存储(即使已加密)。”),但这似乎是处理敏感信用卡的一种非常糟糕的方法。信息...

– Lucero
18/12/23在21:04

IMO,诸如if(!(int(cvv)&& checkCvv(cvv))){返回“它不是有效的CVV”}的错误验证更有可能解释了为什么拒绝这样做,而不是故意的安全性设计决策。

– Lie Ryan
18/12/24在1:49

#2 楼

我可以想到的唯一拒绝这种CVV的弱论点是,如果有人试图强行使用您的3位数代码,那么他们可能首先以000开头(但他们也会拒绝001吗?)。


从实践的角度来看,将“ 000”拒绝为不安全是多么合理?


这不是真的。您可以使用提供的CVC / CVV代码为卡付款,也可以不收取费用。没有充分的理由拒绝此代码,因为它是有效的,并且您无法真正确定信用卡的代码是否有效,直到您尝试对其进行收费为止。

设计糟糕,设计糟糕输入验证太普遍了。一些开发人员倾向于仅假设某些值无效而不检查规格,或者未正确对其输入验证进行单元测试。

一些示例包括:


IP地址1.1.1.1

如果仅字符串中的第一个字符正在检查
具有非字母字符的名称(例如,我的撇号名称)

客服人员甚至在不咨询开发人员的情况下,都会以“不是错误,而是功能”的方式响应您的错误报告,这也很常见。

评论


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

–迈克·卡隆(Mike Caron)
18/12/23在0:47

1.1.1.1甚至更糟,因为人们知道这是一个IP地址,因此决定单方面决定NIC永远不会使用。

–aidanh010
18/12/23在3:18

您可以将电子邮件别名(address+alias@example.com)添加到示例列表中,当有人在没有正当理由的情况下决定更加安全时,这会非常烦人

–Felipe Pereira
18/12/23在13:15

@ gnasher729,这也是没有Windows 9的原因。太多的程序通过检查操作系统名称中是否包含“ Windows 9”来检查操作系统是Windows 95还是98。

–埃里克·杜米尼尔(Eric Duminil)
18/12/24在12:34

我的四个字母的TLD在一些特别愚蠢的网站上引起了电子邮件验证问题。

–轨道轻赛
18/12/25在0:03

#3 楼

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

这是软件错误。他们不能接受。

仅举一个例子:例如,它们在堆栈中的某处使用了一种带有无类型变量的语言(例如,同一变量可以容纳123.45,“晚餐晚饭”,0字符字符串,“未定义”令牌等)。通常这样写:

if ($CVC) # is CVC field present?

在无类型语言中,空白字符串的值按程序员的预期为0(false),但000也是!有更好的方法可以做到这一点。

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

那么为什么他们要声明自己的话呢?由于普通企业非常不愿意承认这种结构性错误,使他们看上去无能为力。但是,它们也无法通过“我不知道”将您送走,因为这具有相同的效果。因此,他们需要立即向您说些对他们而言可售的东西。

显然是错误的;经与您有业务往来的所有其他人的证明,他们对此没有任何问题。但是,请自己尝试;尝试一个竞争性的预订平台,看看如何进行。

评论


在Perl,Python或JavaScript中,字符串000不会得出false。


18/12/23在20:40

好吧,在JavaScript中,如果仅用2个等号比较“ 000”与false(“ 000” == false),它将得出true。

– Steefnotch
18/12/23在21:00

迈克·卡隆(Mike Caron)说的更可能是一种情况:if(!to_number(input))reject()。在Javascript和PHP中,数字零都是虚假的。

– John Dvorak
18/12/23在21:03



@Blrfl我认为要点是,有可能使现代Web堆栈轻松地在边缘情况下破损-有意或无意。后端,中间端,前端等上都有代码,这些代码可能会在未经测试的边缘情况下轻易中断。 JavaScript是最容易被指责的元凶-但正如我关于Null先生(他的真实姓名)的示例所示,当可能迈出任何一步时,都很难将手指指向JS。 (我会说“你得到了bs'd”是答案的不好的一部分……但是其余的都是有效的)

–WernerCD
18/12/24在3:20

@Blrfl我有同意的信息。 Perl,Java,也许是Scala。阅读Isotopp SE SE的最后一段,以了解他的知识:)

–霍布斯
18/12/25在7:51

#4 楼

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

到目前为止,它从未被拒绝过,但是从安全角度来看,我不喜欢它,因为我认为它可以从网站的角度来看,恕我直言,故意将有效数字视为无效是很愚蠢的事情,这是贼可能会首先输入的东西,如果他们以某种方式拥有我的号码而不是我的卡。

(如果发生这种情况的可能性仅为千分之一,就更是如此。)由于该站点非常容易尝试通过很小的授权来确认信用卡,甚至让酒店自行决定,因此,我不会t同意“防止伪造数字”的说法。话虽这么说,多年来,快速搜索使很多人在各种网站上遇到相同的问题。所以,你并不孤单。 :)

评论


我现在知道您的CVV了:)现在只需要搜索公共信用卡违规行为即可……呃……“ TTT”?

–撤消
18/12/28在11:19

#5 楼

公平地说,有成千上万的酒店预订系统必须将booking.com传递给他们的信息进行处理。我相信booking.com可以为知道(000)== FALSE JavaScript的开发人员提供服务...但是值得他们的支持时间来为数百家可能在其中存在此​​错误的酒店诊断出完全相同的错误预订系统?绝对不是。

我的猜测是,这实际上是一种相当合理的尝试,目的是减轻在进一步预订中以及在Booking.com无法控制的系统中发生的数据处理错误。

作为卡处理商,他们有义务处理有效的卡,因此这里可能违反商户规则,可能会给VISA(或任何人)带来麻烦……但我几乎可以理解其逻辑。 />

#6 楼

我在这里用简单的“愚蠢的错误”理论有一些问题。我毫不怀疑您正在与之交谈的人正在胡说八道(因为有些客户服务人员不会这样做)。 000是完全有效的,而且您不是互联网上第一个指出该数字的人。
CVV为0.1%的可能性为000
Booking.com的业务2017年原始收入为80亿美元,大部分来自卡交易。每天大约有五万次中等预订。
因此,Booking.com必须每天遇到000 50次。在Booking.com上损失了$ 25k,而在实际未通过的预订方面损失了很多。

拒绝0.1%的卡交易会造成900万美元的收入损失。在我工作的[非常小]企业中,预订流程分析会很快将其标记在整个链中。这类公司(我本来是在假期预订系统中工作的),购物体验是最受关注的部分……我发现很难相信依赖分析的公司会错过像卡片验证这样简单的事情问题。

因此,如果我们假设这种规模不存在,我们必须提供一些限制范围的建议...



这是本地错误。

许多跨国公司通过当地帐户存钱,然后从那里退税。可能是Booking.com允许其本地办事处在此上编辑代码以处理本地怪癖(货币,非全球性的整体付款方案),并这样做,从而允许其他地方不存在的错误得以蔓延。

因为目标国家是克罗地亚,所以增加了这种可能性。他们在那里使用Kuna,而不是欧元。可能会有大量的会计差异和机制提供者。

这也可以解释为什么这种情况不为人知。克罗地亚约束的资金的0.1%将比全球收入少得多。


000不如0.1%常见

正如JPhi1618在评论中指出的那样,另一个范围限制因素是银行也许不经常发出000。他们没有理由不这样做,正如我所说,网上有其他人拥有000张卡的证据,但这并不是说很普遍。

我没有办法验证这一点。也许拥有包含CVV的卡片处理日志的人可以运行分析。


仍然,如果发现这样的问题,请报告。跳过客户服务团队,因为他们根本不知道发生了什么。请访问CEO或安全团队,因为他们都会因为一些稍有不同的原因而认真对待这一点。 900万美元的收入损失是一个很好的动机。

评论


请注意:我正试图在克罗地亚(不是欧元国家)预订酒店,因此您的推论可能是正确的。

– Vlad Nikiforov
19年1月2日在15:30

我认为使用您的逻辑表明,如果该000数字与预期的一样普遍,Booking.com将被迫解决此问题。他们不会因为十分琐碎的事情而错过1000个预订中的1个。因此,我认为大多数信用卡公司不使用000,而银行OP使用的是一个异常值。

–JPhi1618
19年1月2日,16:39

@ JPhi1618离群值?我不这么认为。几年前,我从一家法国大型银行获得了一张VISA卡,其CVC代码为000(现已过期)。一生都用完了。从未尝试过booking.com。我的猜测:他们的确损失了其收入的0.1%。要找到一家老牌公司的首席执行官可能很困难,安全团队不在乎,当前状态不是安全漏洞。

–StéphaneGourichon
19年1月2日在22:58

“要聘请一家老牌公司的首席执行官可能很困难”。过去曾经如此,但在过去的15年中的某个时刻,似乎似乎已经使高管们亲身体验问题。即使您不能直接交谈,许多人都有内部升级途径。但是,如果这是本地的(看起来可能如此),则可能很难将其反弹到正确的位置。最终,确定将0.1%的付款支付给克罗地亚(他们使用库纳而不是欧元,所以可能使用本地代码)的意愿会有所减轻。

–奥利
19年1月3日,9:57

#7 楼

请注意,在某些信用卡软件上,具有神奇值000的CVC表示已提供CVC,但此后已删除(由于PCI限制)。这可能就是Booking在做的事情,这也解释了为什么他们不接受。