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

Question

安全合法地存储信用卡信息非常困难should not be attempted。我无意存储信用卡数据，但我很想弄清楚以下内容：

我的信用卡信息存储在世界上某个地方的服务器上。该数据（希望）不会存储在商家的服务器上，但在某些时候需要存储该数据以验证并收取由商家提交的数据识别的帐户。

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

Answer 1

如果我存储号码，我将成为一个拥有庞大数据库的巨型服务提供商。该数据库分布在一个高度冗余的存储阵列中，该阵列由多个机柜组成，位于不同的房间或理想情况下位于不同的地理位置，由SAN连接。我最大的内部威胁是分布式物理工厂，不断磨损的驱动器，以及技术人员，管理员和工程师的每日轮班。这是一个巨大的威胁。

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

使用AES等加密。原始AES密钥仅存储在RAM中。密钥包含在每个管理员的PGP文件中，每个管理员都有自己的密码来启用服务器。可以为不太信任的人员提供部分密码以用于灾难恢复，或者密码短语可以存储在某个地方的保险库中。对于加密，为每个卡号选择一个唯一的初始化向量（IV），使用该IV对该号码进行AES加密，并将IV和加密号存储到SAN。仅使用特权客户端接口进行解密;用于购买的普通客户端连接永远不会获得解密。

Answer 2

对于供应商处理和存储您的信用卡信息，他们通常必须获得PCI认证。应概述要求here。有些要求非常简单，有些要求含糊不清，可以解释。完成这个过程并不好玩，拥有认证的公司并不意味着您的数据是安全的。

但这比我想的更好。

Answer 3

存储信用卡号码的盐渍哈希非常容易，而不是数字本身用于安全查找。对于99％的场景，这将是足够的存储信用卡 - 快速且非常安全。

如果您确实需要某种情况下的信用卡可逆加密（例如继续计费），我会使用存储在安全位置的对称密钥其他比数据库。我看了PCI规格已经有一段时间了，但我相当确定它符合PCI标准。

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

修改 我的回答似乎有些争议。我想从Integrity.com（PDF）中指出以下非常有趣的文章：

Hashing Credit Card Numbers: Unsafe Application Practices

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

是的，卡的原始哈希不安全;这就是我们为哈希加盐的原因！但是静态盐也不安全，它们允许为已知的静态盐创建彩虹表。因此，最好让我们的盐以某种不可预测的方式变化。在密码的情况下，对每个被检查的密码使用单独的随机哈希就足够了;它甚至可以与散列密码位于同一个表/行中。对于信用卡的情况，这应该是相同的 - 每个信用卡实例的随机盐被散列。如果每笔交易存储信用卡号，则每笔交易都有一个单独的盐。

这种方法有利有弊，但它足够安全。专业人士缺乏关键管理; salt和hash就在那里，不需要改变，同时仍允许对哈希进行审计检查;例如该信用卡哈希是否与此已知的信用卡号匹配？

利弊正在搜寻中;在许多交易中无法有效地搜索特定的信用卡号。

当然，无论如何，你都会遇到外部加密问题;除非数据库本身是加密的（只有某些数据库支持），否则您将无法很好地搜索。即便如此，在数据库甚至表级加密也会显着降低搜索效率。

Answer 4

我最近几次使用信用卡付款，您从未真正将实际的CC信息存储在您自己的服务器上。您让付款网关处理该问题。您最终得到的是一个transactionID，您可以用它来验证信用卡是否仍然有效并且具有所请求的现金数量。然后，一旦你真正打包了他们购买的东西，你就会向支付网关发出一个捕获命令。

这种方法大大简化了在网站上集成CC支付的过程，因为您需要知道的只是特定客户的transactionID。这个当然不允许你做亚马逊 - “技巧”保持你的CC信息的一键购物。如果transactionID遭到入侵，它可以用于提前收款或完全取消交易（在这种情况下，当您在发货前验证授权仍然有效时，您会发现它）。该交易不能用于收取比客户已经批准的金额更大的金额，也不会允许某人收集到与“商店”配置的帐户不同的帐户。

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

Answer 5

在某些情况下，加密密钥不存储在磁盘上，而是存储在某些硬件设备上。使用特殊加密服务器进行加密/解密，或者使用存储在硬件加密狗上的密钥完成解密。这样，黑客就不会在没有窃取包含它们的物理设备的情况下窃取解密密钥（因为密钥永远不会离开设备）。

我看到的另一种方法是将加密数据存储在与外界无直接连接的数据库/数据中心中（您无法破解无法访问的内容）。接口服务器位于网络的“安全”部分和作为代理的网络的“面向Internet”/“不安全”部分之间。通过此安全阻塞点强制安全流量进入漏斗可能会使入侵者更难以访问受保护的数据。

当然，这些都不意味着您的数据非常安全。

Answer 6

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

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

Answer 7

首先，如果您处理信用卡号码，则需要符合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.因此，任何2个驱动器都需要构建一个完整的密钥（A + B + C）。该方案可以容忍丢失任何一个驱动器。关键部件本身使用只有驱动器所有者知道的密码进行加密。

Answer 8

您假设商家必须以某种方式存储卡是不正确的。最有可能的是，商家正在存储您第一次使用该卡时从支付处理网关收到的令牌。令牌唯一地标识商家和卡的组合。随后，您可以从该商家购物而无需再次提供您的卡号。如果商家的数据库遭到破坏，则令牌对攻击者来说几乎没有价值。它们仅对该商家有效，并且一旦检测到违规行为，它们都可以立即取消。

Answer 9

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

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

PCI审核员无法确保一切都正确完成。

Answer 10

如果您想消除任何信用卡窃取头痛，请使用未存储在数据库中的salt值（除了存储在数据库中的salt值之外）对它们进行哈希处理。使用任何现代哈希算法对它们进行哈希处理几乎可以解决大多数信用卡被盗问题，但这确实意味着消费者必须在每次购买时重新输入信用卡。在处理了一个处理信用卡号码存储的项目后，我发现他们将安全审查成本降低了一个数量级（授予该项目在PII关注之前）。

如果您要使用对称加密，那么您将进入复杂的新领域，所有这些都归结为管理和控制解密密钥。我会说，即使您使用信用卡号码，您仍然需要处理可逆加密，因为所有PII（个人身份信息）都必须加密。 SQL Server 2008有一个新的可扩展密钥管理插件体系结构，它允许使用第三方供应商程序来管理对解密密钥的控制，包括拆分密钥。

欲了解更多信息： Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.

Answer 11

任何用于解密加密信息的自动化系统都将完全不安全。通过自动化流程，您将破坏加密。任何加密数据都只能由用户输入的密钥解密。