有人正在存储信用卡数据 - 他们是如何做到的？

Question

有人正在存储信用卡数据 - 他们是如何做到的？

55

存储信用卡信息既需要安全性，又要符合法律要求，非常困难，因此不应该尝试。我没有存储信用卡数据的意图，但我渴望弄清以下问题：

我的信用卡信息被存储在世界某个地方的服务器上。这些数据（希望如此）未被存储在商户的服务器上，但是需要存储以验证并收取商户提交数据所确认的账户。

我的问题是：如果您被要求存储信用卡数据，您会使用什么加密策略来保护硬盘上的数据？据我所知，提交的信用卡信息正在实时或近实时地进行检查。我怀疑用于保护数据的任何加密密钥都不是手动输入的，因此解密是在运行中完成的，这意味着密钥本身被存储在硬盘上。在这样的自动化系统中，您将如何保护您的数据和密钥？

- leepowers

我们付钱让他们为我们完成了这件事 :) - Josh Stodola

+1 但我确实觉得这个问题非常有趣，因为几年前我也问过自己这个问题！ - Josh Stodola

1

我刚刚读到这个。听起来像是一个阴谋论的耳语。“嘿，伙计们，有人正在存储信用卡数据……嘘……他们是怎么做到的？” - Jeff Yates

2

这不会回答你的问题，只是对“在某个时候需要存储信用卡信息”的假设发表评论：从理论上讲，这甚至不是必要的——如果只有SET获得了更多的关注：http://en.wikipedia.org/wiki/Secure_Electronic_Transaction - Chris Lercher

2

我曾参与一家大型酒店连锁的系统开发合约。他们的解决方案是使用一个扁平文件数据库，不仅存储卡号，还存储任何刷过的卡片的原始数据轨迹。明文存储在每个前台下的箱子中，使用同样的（广为人知的）根密码在全国范围内使用。那时距离PCI标准出台还有大约3年时间。我希望现在情况已经得到了改善。 - Brad The App Guy

11个回答

19

一般情况下，商家要处理和存储你的信用卡信息，通常需要获得PCI认证。相关要求应在这里列出。其中有些要求非常简单明了，而其他要求则含糊不清，需要解释说明。完成认证过程并不愉快，而且公司获得认证并不意味着你的数据是安全的。

但我想这总比没有强吧。

- i_am_jorf

6

同意。许多被黑客攻击并且信用卡信息被盗的公司都符合PCI合规要求。这不是解决所有问题的唯一方法。 - John Conde

2

约翰说得非常正确 - 实际上，许多公司对安全问题持有一种自满的态度，仅仅因为他们达到了PCI的要求，导致他们的管理层认为他们是安全的。 - wadesworld

1

符合PCI标准相当无用。他们只是听取填写问卷的人的话来确定是否符合PCI标准。问题的性质如下：你的某某是否安全？试图获得PCI合规性的人会怎么回答呢？ - OverClocked

3

只有非常小的邮购式客户可以使用自我评估问卷。大多数电子商务商家都需要引入独立的合格安全评估师。如果你撒谎并被发现，你将被罚款并列入黑名单。 - PaulG

2

@Overclocked：此外，他们必须从授权的安全供应商那里获得漏洞扫描，这意味着他们不能仅仅回答调查来假定符合要求。 - Jason M

3

将信用卡号的加盐哈希值存储起来而不是存储卡号本身以进行安全查找非常容易。对于99％的情况来说，这足以作为存储信用卡的方式 - 快速且非常安全。

如果您真的需要对信用卡进行可逆加密以满足某些方案的需求（例如持续计费），我建议使用对称密钥存储在数据库之外的安全位置。虽然我已经有一段时间没有看PCI规范了，但我相当确定这符合PCI标准。

如果您需要快速查找和可逆加密，请同时使用这两个选项：哈希和加密。

编辑： 我的回答似乎存在一些争议。我想指出以下来自Integrity.com（PDF）的非常有趣的论文：

哈希信用卡号：不安全的应用实践

它详细介绍了存储信用卡数据哈希值涉及的许多问题，但其结论证实了我的建议。

是的，卡片的原始哈希值并不安全；这就是为什么我们要对哈希值进行加盐处理！但是静态盐也不安全，它们允许为已知静态盐创建彩虹表。因此，最好使我们的盐以某种不可预测的方式变化。对于密码，使用单独的随机哈希值来检查每个密码就足够了；它甚至可以与哈希密码位于同一个表/行中。对于信用卡也应该是相同的做法——为每个需要哈希的信用卡实例使用随机盐。如果信用卡号每次交易都存储一次，则每次交易都需要单独的盐。

这种方法有利有弊，但足够安全。优点在于没有密钥管理；盐和哈希值就在那里，而且不需要改变，同时仍然允许对哈希值进行审计检查；例如，这个信用卡哈希值是否与已知的信用卡号匹配？

缺点在于搜索；在许多交易中无法有效地搜索特定的信用卡号。

当然，使用外部加密时也会遇到这个问题；除非数据库本身已经加密（只有一些数据库支持），否则您将无法进行很好的搜索。即使在数据库甚至表级别进行加密也会显著降低搜索效率。

- Randolpho

1

这是错误的建议。信用卡号码并不是非常随机的。除非你精心设计你的实现，否则它将不安全，因为哈希可以被暴力破解。 - Turtle

但是盐是公开的，因此拥有盐和哈希，相对容易地测试所有可能的信用卡号码是否匹配。 - Kris

只有当盐是公共的且静态的时才如此。盐应始终是特定于事务的。我将修改我的答案来解释这一点。 - Randolpho

3

我认为@Turtle说得还是对的。问题不在于彩虹表可以用来解密其他卡的哈希值，而在于信用卡没有容错空间。对于密码，用户可以（希望）选择任意长度的数字、字母和符号。这并不容易被暴力破解，但对于信用卡，常常将前4位和后4位存储为明文文本，这只留下8个未知数字。即使这些数字完全随机，你需要尝试1亿次才能保证获得完整的数字，没有任何疑问。 - Mike

我想更新一下我的上一个评论。PCI DSS v3第3.4节确实允许对卡进行哈希处理，但必须采取极大的预防措施。它必须基于强加密（因此md5 / sha1不行，希望您选择某些缓慢的算法），必须使用随机盐来防止彩虹表查找，哈希值必须是整个卡的哈希值，并且哈希值和截断的卡号（即第一个和最后几位数字）绝不能接触。如果您要对客户的卡进行哈希处理，请仔细研究PCI DSS第3.4节以确保正确操作，并确保您也阅读了文档的其余部分！ - Mike

2

您的假设商家必须以某种方式存储卡片是不正确的。很可能，商家正在存储第一次使用卡片时从支付处理网关收到的令牌。该令牌唯一地标识了商家和卡片的组合。随后，您可以在该商家处进行购买而无需再次提供您的卡号。如果商家的数据库受到攻击者的攻击，那么这些令牌对攻击者来说价值很小。它们只对该商家有效，并且在检测到违规行为时可以全部取消。

- Kevin Krumwiede

2

在处理信用卡支付时，最近几次的做法是不在自己的服务器上存储实际的信用卡信息，而是让支付网关来处理。你最终得到的是一个交易ID，你可以使用它来验证信用卡是否仍然有效，并且拥有所请求的金额。然后，一旦你实际打包他们购买的物品，你会向支付网关发出一个捕获命令。

这种方法极大地简化了网站集成信用卡支付的过程，因为你所需要知道的只是某个客户的交易ID。当然，这并不允许你像亚马逊那样保留客户的信用卡信息以进行一键购物。如果交易ID被泄露，它只能用于提前收款或完全取消交易（在这种情况下，在发货之前验证授权是否仍然有效时，你会发现它）。该交易不能用于收取比客户已经批准的更大金额，也不会允许某人收取到与“商店”配置的不同账户。

也许不是你要找的确切答案，但也许它可以解决你的整体问题，而无需花费大量资金在安全供应商身上。

- Grubsnik

1

在某些情况下，加密密钥不是存储在磁盘上，而是存储在某些硬件设备上。可以使用特殊的加密服务器进行加密/解密，或者使用存储在硬件加密狗等设备上的密钥进行解密。这样，黑客就无法窃取解密密钥，除非窃取包含密钥的物理设备（因为密钥从未离开设备）。

我见过的另一种方法是将加密数据存储在与外部世界没有直接连接的数据库/数据中心中（你无法访问的东西无法被黑客攻击）。一个接口服务器作为代理位于“安全”网络部分和“面向互联网”/“不安全”网络部分之间。强制安全流量通过此安全瓶颈可以使入侵者更难访问受保护的数据。

当然，这两种方法都不能保证您的数据完全安全。

- bta

1

作为商家，您可以选择将信用卡数据存储在自己的数据库中或外包给第三方提供商。
像IPPayments这样的第三方提供商或澳大利亚的主要银行，如Westpac，都符合一级PCI合规标准。对于Web应用程序，您可以选择使用一个付款接受网页（在客户工作流程的某个位置呈现），并为其品牌化以适合您的公司。对于Windows应用程序（例如您公司的CRM应用程序）和经常性付款，它们通常具有可使用其API的网关，提供令牌化服务，即它们接受CC号码，注册它并返回一个看起来像CC号码的唯一令牌。该令牌可以安全地存储在您的数据库中，并用于任何进一步的交易、批量支付、对账等与银行相关的操作。当然，重要的问题是每笔交易的运营成本。对于从一百万客户那里收取月度信用卡付款的实用程序，交易成本可能相当高。

如果您选择将信用卡号存储在自己的数据库中，三重DES加密就足够了。更好的选择是使用Oracle高级安全或SQLServer提供的透明加密，在数据库中，即使是DBA也无法解密信用卡号。然后，还有繁琐的密钥管理、备份、物理安全、网络安全、SSL传输、更改所有服务器设备和防火墙的默认设置、防病毒、审计、安全摄像头等责任。

- softveda

1

首先，如果您处理信用卡号码，您需要成为PCI-DSS合规，并且一旦您存储号码，PCI-DSS规范的所有12个部分都将适用于您。这对大多数组织来说是一个重大的成本，如果您没有时间、资源和财力，就不应该存储信用卡号码。

我们已经在一个基于Windows的电子商务系统上获得了PCI-DSS合规性，该系统存储信用卡信息。它使用256位AES加密。密钥本身使用Windows DPAPI进行加密，这意味着只有在与加密它的用户帐户下运行的进程才能解密加密密钥。加密密钥存储在注册表中。

密钥每12个月轮换一次，并且备份密钥副本被分成3部分A、B、C并分别存储在由不同人持有的3个USB驱动器中。驱动器1具有A+B，驱动器2具有B+C，驱动器3具有A+C。因此，需要任意两个驱动器才能构建完整的密钥（A+B+C）。该方案对于任何一个驱动器的丢失都是容忍的。密钥部分本身使用仅由驱动器所有者知道的密码进行加密。

- saille

那是不正确的，或者也许时代已经改变了。我知道有几个符合PCI SAQ-D标准（最高和最严格的PCI合规性水平）的处理器可以为您处理服务器和安全性，然后您只需要使用加密等方式安全地存储卡数据即可。总体而言，每月最多花费800美元。 - eozzy

0

回答您的具体问题，将信用卡加密密钥加密存储在磁盘上是可能的。加密密钥可以从必须在服务器启动时输入的密码短语中派生出来。可以使用Shamir的秘密分割方案，以便需要k个N份才能构建将用作密钥加密密钥的秘密。然后在内存中存储解密的加密密钥/秘密。如果必须重新启动服务器，则需要k份共享。当然，这是一个很大的开销，我认识的大多数商家都没有实现这一点。但是，他们通常会将密钥与加密数据分开存储，以获得一些中间安全性，因此访问其中一个不会自动意味着完全访问另一个（尽管仍然非常糟糕）。

我删除了原帖子的内容，因为那并没有直接回答问题。可以说，密钥管理和正确的加密是重要的一部分，但仍然只是故事的一小部分。

PCI审计员不可能确保一切都做得正确。

- mar

0

如果您想消除任何信用卡盗窃的烦恼，可以使用不存储在数据库中的盐值对其进行哈希处理（除了存储在数据库中的盐值）。使用任何现代哈希算法对其进行哈希处理基本上可以解决大多数信用卡盗窃问题，但这意味着消费者必须在每次购买时重新输入他们的信用卡信息。我曾经参与过一个处理信用卡号码存储的项目，发现将它们哈希处理可以将安全审查成本降低一个数量级（尽管该项目是在个人身份信息（PII）问题出现之前）。

如果您要使用对称加密，则会进入一个新的复杂领域，所有问题都归结为解密密钥的管理和控制。我会说即使您对信用卡号码进行哈希处理，仍然需要处理可逆加密，因为所有PII（个人身份信息）都必须加密。SQL Server 2008具有新的可扩展密钥管理插件架构，可以使用第三方供应商程序来管理解密密钥，包括分裂密钥。

更多信息：基于支付卡行业数据安全标准（PCI DSS）版本1.2部署SQL Server 2008。

- Thomas

我猜“使用秘密盐进行哈希”相当于使用某种MAC。 - Kris

如果您这样做，请务必确保不要同时存储信用卡号的某些片段。您可能会想要存储数字的最后四位，以便向用户显示它。然而，鉴于前几位数字的非常可预测的格式，如果攻击者拥有哈希和最后四位数字，实际上可以通过暴力破解来获取完整的信用卡号码...我已经做到了！ - MtnViewMark

1

你肯定没有不使用所有的盐值。简单的解决方案是有两个盐值：一个针对每个条目，一个在数据库之外。你必须拥有这两个值才能进行合理的暴力破解。 - Thomas

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Daniel Newby · Accepted Answer

如果我要存储这些数字，我将成为一个具有庞大数据库的巨型服务提供商。该数据库分布在一个高度冗余的存储阵列中，由多个机柜组成，分别位于不同的房间或理想情况下分布在不同的地理位置，并通过SAN连接。我的最大内部威胁是分布式物理设施、不断更换的硬盘和每天几个班次的技术人员、管理员和工程师。这是一个巨大的威胁。

因此，我会在与大容量存储设备通过网络连接的物理上隔离的计算机上加密数据。软件应尽可能简单：加密和数字验证。公共接口和业务逻辑放在其他地方。访问将被记录到一个单独的SAN中。

使用类似AES的加密算法进行加密。原始的AES密钥仅存储在RAM中。该密钥用PGP文件封装，并为每个管理员设置自己的密码以启用服务器。可以向不太信任的人员提供部分密码以在灾难恢复时使用，或将密码存储在保险库中。对于加密，请选择每个卡号的唯一初始化向量（IV），使用该IV对卡号进行AES加密，并将IV和加密后的数字存储到SAN中。解密仅在特权客户端接口上进行；用于购买的正常客户端连接永远不会获得解密。