存储部分信用卡号

Posted

技术标签:

【中文标题】存储部分信用卡号【英文标题】:Storing partial credit card numbers 【发布时间】:2010-12-01 21:49:22 【问题描述】:

可能的重复:

    Best practices for taking and storing credit card information with php Storing credit card details Storing Credit Card Information

我需要在电子商务网站中存储信用卡号。我不打算存储整个信用卡号,因为这将是非常危险的。我想至少存储前五位数字,以便以后识别发卡的金融机构。理想情况下,我希望尽可能多地存储信用号,以帮助将来进行交叉引用等。

我可以安全存储多少位数字以及哪些特定数字?

例如,我认为这不够安全:

5555 5555 555* 4444

因为你可以计算出丢失的数字。

同样,这将是安全的,但没有那么有用:

5555 5*** **** ****

是否有一种被广泛接受的存储部分信用号码的模式?

【问题讨论】:

最后 4 位数字应该没问题。但请检查我添加的可能重复的问题。 【参考方案1】:

支付卡数据安全标准规定,如果您要处理持卡人数据,那么您将受到 PCI DSS 的约束(这是非常全面的,并且很难遵守)。如果您想存储卡号的一部分,并且不想处理标准,那么您需要确保 a) 您存储NO MORE THAN the first 6 and last 4 digits; b) 您永远不会存储、处理或传输更多信息。这意味着必须在数据进入您的控件之前执行截断。

鉴于您谈论的是电子商务网站,我认为您迟早必须处理 PCI DSS(因为如果您不使用完整的 PAN,则无法处理交易)。因此,实际上,您应该避免存储超过 PAN 的前 6 位和后 4 位;然后标准不会“关心”这些数据,您可以将其存储为您认为合适的任何形式。例如,如果您存储前 7 位数字,则标准的要求 3 开始生效(您开始必须真正了解加密中的密钥管理)。

希望对你有用。

【讨论】:

有人对此有任何实际参考吗?例如“标准然后不'关心'这些数据” ... BK 是正确的 - 这是 PCI 的官方答案:selfservice.kb.net/article.aspx?article=9488&p=81 @chrishiestand,链接好像过期了,如果你有办法再次找到那个答案应该会很好......【参考方案2】:

2013 年 3 月编辑: 一个非常相关的资源是PCI Security Standards Council,该组织于 2006 年由五个全球最大的信用卡品牌(AmEx、Visa、MasterCard、JCB International 和 Discovery)成立,它是支付卡安全事务的事实上的权威机构工业 (PCI)。 该组织特别发布了PCI Data Security Standard,当前版本为 2.0 版,涵盖诸如管理完整或部分信用卡号等问题。本文档(如果免费提供,但需要简单注册并确认许可条款)。

以下为原文,c. 2009 年的答案,大部分是正确的,但都是杜撰的。 一种常见的做法(我不知道是否合法)是存储最后 4 位数字,因为这可以用来帮助客户确认他/她的哪些信用卡用于特定的交易。

在不显着提高恶意人员猜出完整号码的几率的情况下,可以存储代表发卡金融机构的前 4 位数字,如问题中所述。

不要,保存比这 8 个数字更多的数字,否则,鉴于 LUHN-10 checksum,您可能会提供足够的信息来使猜测完整的数字更加合理(如果仍然相对困难,甚至从给定发行人在给定时间段内使用的系列中获得洞察力,但应该小心...)

为了使整个事情在技术上和法律上更安全,您可以考虑仅在客户明确允许的情况下存储此类信息。您还应该考虑使用用于存储在数据库中的简单哈希来屏蔽此信息。

此外,您可以/应该在特定交易之后存储的是信用卡处理器在提交交易时提供的交易 ID。此 ID 是允许定位您甚至需要的大部分(全部?)信息的关键,特定交易是否存在任何问题。这种类型的信息通常可以从处理公司维护的安全网站查询,以及一些汇总报告,其中可能包括按卡类型(美国运通、维萨...)分组,如果这就是您考虑存储的原因前四个。

【讨论】:

【参考方案3】:

如果您不需要存储整个信用卡号,为什么还需要存储呢?如果要保存发卡的金融机构,为什么不保存发卡的金融机构呢?

【讨论】:

作为用户,查看特定交易使用的卡对我很有用。我可以判断一个网站是否仍在使用我丢失并取消的卡上的旧号码,或者它是否在使用我的新卡。【参考方案4】:

PCI/DSS 文档的第 3.3 节回答了您的具体问题。 前六个和后四个是最大的显示。客户(纸质?)收据更具限制性。那些有合法需要知道的人可以看到完整的卡片数据。

我的建议是联系您的商家提供商,看看您可以使用哪些选项。许多现代交易网关具有“保险库”功能,其中敏感信息存储在提供商处,当您想要向客户收费或查看帐户信息时,您只需通过令牌编号引用客户。

同样,交易特定令牌的使用可用于引用存储在提供程序系统上的所需数据。

但是,我怎么强调阅读和理解 PCI DSS 的重要性都不为过。简单地使用安全存储并不会神奇地使您不受 PCI 合规性要求的约束!!这只有在您的系统从不接触完整卡数据时才有可能。

【讨论】:

“阅读和理解 PCI DSS。”是的,祝你好运。 :) 老实说,一旦信用卡公司开始严格执行此规定,每个开发人员都将需要访问可能具有法律能力的专家,以确保他们的软件和硬件符合标准。它绝对不是为普通计算机程序员编写的。【参考方案5】:

接受的模式是根本不存储它们。

在某些司法管辖区,存储它们或它们的任何部分可能会触犯法律。

您可以改为存储信用卡号的单向(因此不可恢复)哈希。

【讨论】:

单向哈希不是一个坏主意。它可以让我确定两个信用卡号是否相同。谢谢你的主意!但是,我还想存储部分数字。但是,也许前五位数字以及哈希就足够了.. 我不同意所有观点。存储卡数据并不违法。安全存储和处理的要求由卡行业管理。 PCI/DSS 要求可在线获取,无论您是否存储数据都适用!!在这种情况下单独使用散列算法通常是非常危险的,因为卡号的熵很低,并且使用预计算表和其他蛮力技术很容易完成原始数字的覆盖块大小恢复。 我不同意。存储卡数据是有正当理由的,只是说不这样做并不能回答乔尔提出的具体问题。 定期自动向客户收费的订阅服务。为用户提供方便的资金选择的电子商务网站。许多受人尊敬的系统(PayPal..et al)存储卡数据。您显然是正确的,但是可以减轻此类风险-不存储它们并不是一开始就没有安全系统的借口。攻击者可以很容易地点击交易并将它们“存储”在他们自己的数据库中。 我相信其他人更有资格为您绘制完整的威胁树。这可以通过破坏电子商务服务器和安装必要的软件来实现。我不同意你的观点,但我们都必须生活在我们这个时代的背景下。恕我直言,理想的解决方案是用用户发起资金转移(本质上是 PayPal)的“给予”系统替换当前的“获取”模式。而不是商家从客户那里收取资金。【参考方案6】:

信用卡公司对此有一个标准。您可能会发现它隐藏在您的支付处理器的服务条款中的某个地方,您将遵守此标准。它回答你的问题。你可以找到标准的here

【讨论】:

【参考方案7】:

在加拿大,通常的方法是存储前 4 位数字(用于标识金融机构)和最后 4 位数字以标识信用卡。

但请确保您没有违反任何法律。

【讨论】:

以上是关于存储部分信用卡号的主要内容,如果未能解决你的问题,请参考以下文章

存储信用卡号 - PCI?

python:双向部分信用卡存储加密

在 SQL Server 中屏蔽信用卡号

验证信用卡号

正则表达式识别商店信用卡号

防止重复使用信用卡的最佳方法