安全合法地存储信用卡信息非常困难，不应尝试。我无意存储信用卡数据，但我很想弄清楚以下内容：
我的信用卡信息存储在世界某个地方的服务器上。此数据（希望）不会存储在商家的服务器上，但在某些时候需要存储它以验证商家提交的数据所标识的帐户并对其收费。
我的问题是：如果您的任务是存储信用卡数据，您将使用哪种加密策略来保护磁盘上的数据？据我所知，提交的信用卡信息或多或少会被实时检查。我怀疑任何用于保护数据的加密密钥都是手动输入的，因此解密是在运行中完成的，这意味着密钥本身存储在磁盘上。在这样的自动化系统中，您将如何保护您的数据和密钥？
如果我存储数字，我将成为拥有庞大数据库的大型服务提供商。该数据库分布在一个高度冗余的存储阵列中，该阵列由多个机柜组成，位于不同的房间或理想的不同地理位置，由 SAN 连接。我最大的内部威胁是分布式物理设备、源源不断的破旧驱动器以及技术人员、管理员和工程师的每日轮班。这是一个巨大的威胁。
因此，我会在通过网络连接到大容量存储的物理隔离计算机上加密数据。该软件将尽可能简单：加密和号码验证。公共接口和业务逻辑放在别处。访问将被记录到单独的 SAN。
用 AES 之类的东西加密。原始 AES 密钥只存储在 RAM 中。密钥包含在每个管理员的 PGP 文件中，每个管理员都有自己的密码来启用服务器。可以为不那么受信任的人员提供部分密码以用于灾难恢复，或者可以将密码存储在某个地方的保险库中。对于加密，为每个卡号选择一个唯一的初始化向量 (IV)，使用该 IV 对号码进行 AES 加密，并将 IV 和加密后的号码存储到 SAN。仅使用特权客户端接口进行解密；用于购买的普通客户端连接永远无法解密。
对于要处理和存储您的信用卡信息的供应商，他们通常必须获得 PCI 认证。此处应概述这些要求。一些要求非常简单明了，而另一些要求则含糊不清，易于解释。经历这个过程并不有趣，拥有认证的公司并不意味着您的数据是安全的。
但我想这总比没有好。
存储信用卡号的加盐哈希而不是数字本身以进行安全查找非常容易。对于 99% 的场景，这将是足够的信用卡存储 - 快速且非常安全。
如果您确实需要在某些情况下对信用卡进行可逆加密（例如，继续计费），我会使用存储在数据库以外的安全位置的对称密钥。自从我查看 PCI 规格以来已经有一段时间了，但我相当确定这是符合 PCI 标准的。
如果您需要快速查找和可逆加密，请使用两个选项：哈希和加密。
编辑： 我的回答似乎存在一些争议。我想指出以下来自 Integrity.com 的非常有趣的文章 (PDF)：
它详细说明了存储信用卡数据哈希所涉及的许多问题，但其结论证实了我的建议。
是的，卡的原始哈希是不安全的；这就是我们为哈希加盐的原因！但是静态盐也不安全，它们允许为已知的静态盐创建彩虹表。所以最好让我们的盐以某种不可预测的方式变化。在密码的情况下，对每个被检查的密码使用单独的随机散列就足够了；它甚至可以与散列密码位于同一个表/行中。对于信用卡，这应该是相同的——每个信用卡实例的随机盐被散列。如果信用卡号在每笔交易中存储，则为每笔交易单独存储一个盐。
这种方法有利有弊，但它足够安全。优点是缺乏密钥管理；盐和哈希就在那里，不需要更改，同时仍然允许对哈希进行审计检查；例如，该信用卡哈希是否与该已知信用卡号匹配？
缺点正在搜索中；不可能在许多交易中有效地搜索特定的信用卡号。
当然，无论如何，您都会遇到外部加密的问题。除非数据库本身是加密的（只有某些数据库支持），否则您将无法很好地搜索。即便如此，在数据库甚至表级别进行加密也会显着降低搜索效率。
最近几次我使用信用卡付款时，您从未真正将实际的 CC 信息存储在您自己的服务器上。你让支付网关来处理。您最终得到的是一个 transactionID，您可以使用它来验证信用卡仍然有效并且具有请求的可用现金金额。然后，一旦你真正打包了他们购买的东西，你就会向支付网关发出一个捕获命令。
这种方法大大简化了在网站上集成 CC 支付的过程，因为您只需要知道特定客户的 transactionID。这当然不允许您使用亚马逊保留您的 CC 信息以进行一键购物的“技巧”。如果 transactionID 被泄露，它只能用于提早收款，或完全取消交易（在这种情况下，当您在发货前验证授权仍然有效时，您会发现它）。该交易不能用于收取比客户已经批准的金额更大的金额，也不允许某人收取与“商店”配置不同的帐户。
也许不是您正在寻找的确切答案，但也许它可以解决您的整体问题，而无需在安全供应商上花费一大笔钱。
您认为商家必须以某种方式存储卡的假设是不正确的。最有可能的是，商家正在存储一个令牌，该令牌是您第一次使用该卡时从支付处理网关收到的。令牌唯一标识商户和卡的组合。随后，您无需再次提供您的卡号即可从该商家处购物。如果商家的数据库遭到破坏，那么这些令牌对攻击者来说就没有什么价值了。它们仅对该商家有效，并且在检测到违规时可以立即取消。
在某些情况下，加密密钥不是存储在磁盘上，而是存储在某些硬件设备上。要么使用特殊的加密服务器进行加密/解密，要么使用存储在硬件加密狗上的密钥完成解密。这样，黑客就无法在不窃取包含解密密钥的物理设备的情况下窃取解密密钥（因为密钥永远不会离开设备）。
我见过的另一种方法是将加密数据存储在与外界没有直接连接的数据库/数据中心中（您无法破解您无法访问的内容）。接口服务器作为代理位于网络的“安全”部分和网络的“面向 Internet”/“不安全”部分之间。强制安全流量通过此安全阻塞点可能会使入侵者更难访问受保护的数据。
当然，这些都不意味着您的数据是完全安全的。
作为商家，您可以选择将 CC 数据存储在您自己的数据库中或将其外包给第三方提供商。IPPayments
等第三方提供商 或Westpac等主要银行在澳大利亚符合 1 级 PCI 标准。对于 Web 应用程序，您可以选择使用他们为您的公司打上烙印的付款接受网页（显示在客户工作流程中的某处）。对于 Windows 应用程序（例如贵公司的 CRM 应用程序）和经常性支付，他们通常有一个网关可用，使用他们的 API 提供标记化服务，即他们接受一个 CC 号码，注册它并返回一个看起来像 CC 号码的唯一令牌. 令牌可以安全地存储在您的数据库中，并用于与银行的任何进一步交易、批量支付、对账等。当然，他们最大的问题是每笔交易的运营成本。对于一个每月从一百万客户那里收取信用卡付款的公用事业公司，交易成本可能很高。
如果您选择将 CC 编号存储在您自己的 DB 中，三重 DES 加密就足够了。更好的选择是 Oracle 高级安全或 SQLServer 提供的 DB 中的透明加密，即使 DBA 也无法解密 CC 编号。然后是密钥管理，备份，物理安全，网络安全，SSL传输，更改所有服务器设备和防火墙的默认设置，防病毒，审计，安全摄像头等等……
首先，如果您处理信用卡号码，则需要符合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）。该方案可以容忍任何 1 个驱动器的丢失。关键部件本身使用只有驱动器所有者知道的密码进行加密。
要回答您的具体问题，可以将加密的信用卡加密密钥存储在磁盘上。密钥加密密钥可以从服务器启动时必须输入的密码短语派生而来。可以使用 Shamir 的秘密拆分方案，因此需要 N 个共享中的 k 个来构造将用作密钥加密密钥的秘密。然后将解密的加密密钥/秘密存储在内存中。如果必须重新启动服务器，则需要 k 个共享。这当然是一个很大的开销，我认识的大多数商家都没有实现这一点。然而，他们通常将密钥与加密数据分开存储，以实现一些中间安全性，因此访问一个并不意味着完全访问另一个（尽管仍然非常糟糕）。
我删除了我原来帖子的内容，因为那没有直接回答这个问题。可以说，密钥管理和正确加密是重要的部分，但仍然只是故事的一小部分。
PCI 审核员不可能确保一切都正确完成。
如果您想消除任何信用卡盗窃问题，请使用未存储在数据库中的盐值（除了存储在数据库中的盐值）对它们进行哈希处理。使用任何现代散列算法对它们进行散列几乎可以解决信用卡盗窃的大多数问题，但这确实意味着消费者必须在每次购买时重新输入他们的信用卡。在从事过一个处理信用卡号码存储的项目后，我发现对它们进行散列可以将安全审查成本降低一个数量级（假设该项目在 PII 问题之前）。
如果您要使用对称加密，那么您将进入一个复杂的新领域，这一切都归结为对解密密钥的管理和控制。我会说，即使你对信用卡号码进行哈希处理，你仍然需要处理可逆加密，因为所有 PII（个人身份信息）都必须加密。SQL Server 2008 有一个新的可扩展密钥管理插件体系结构，它允许使用第三方供应商程序来管理对包括拆分密钥在内的解密密钥的控制。
任何用于解密加密信息的自动化系统都将完全不安全。通过自动化该过程，您正在击败加密。任何加密数据只能由用户输入的密钥解密。