有人正在存储信用卡数据 – 他们怎么做？
存储信用卡信息安全合法是非常困难的， 不应该尝试 。 我无意存储信用卡数据，但我很想弄清楚以下几点：
我的信用卡信息正被存储在世界上某个服务器上。 这个数据（希望）不会被存储在商家的服务器上，但是在某个时候它需要被存储以validation由商家提交的数据识别的账户并对其进行收费。
我的问题是：如果您的任务是存储信用卡数据，您将使用哪种encryption策略来保护磁盘上的数据？ 从我可以告诉提交的信用卡信息正在或多或less被实时检查。 我怀疑用于保护数据的任何encryption密钥是手动input的，因此解密正在进行中，这意味着密钥本身被存储在磁盘上。 你将如何保护你的数据和你的钥匙在这样的自动化系统？
如果我储存了这个号码，我将成为一个拥有庞大数据库的巨型服务提供商。 该数据库分散在由多个机柜组成的高度冗余的存储arrays中，分散在不同的房间中，或理想地分散在不同的地理位置，由SAN连接。 我最大的内部威胁是分布式的物理工厂，不断stream出的驱动器，以及技术人员，pipe理员和工程师的日常工作。 这是一个巨大的威胁。
因此，我将在通过networking连接到海量存储的物理隔离计算机上encryption数据。 该软件将尽可能简单：encryption和号码validation。 公共接口和业务逻辑走到别处。 访问将被logging到单独的SAN。
用AESencryption。 原始的AES密钥只存储在RAM中。 密钥被封装在每个pipe理员的PGP文件中，他们拥有自己的密码来启用服务器。 信任度较低的人员可以使用部分口令在灾难恢复中使用，或者口令可以存储在某个地方的Vault中。 对于encryption，为每个卡号select唯一的初始化vector（IV），使用该IV对AES进行AESencryption，并将IV和encryption号码存储到SAN。 解密只能使用特权客户端界面进行; 用于购买的正常客户端连接永远不会得到解密。
对于供应商来处理和存储您的信用卡信息，他们通常必须获得PCIauthentication。 这些要求应该在这里列出。 其中一些要求非常简单，另一些要求是模糊的，并且可以解释。 通过这个过程并不好玩，一个拥有authentication的公司并不意味着你的数据是安全的。
但是，我认为这总比没有好。
存储一个信用卡号码的腌制散列很容易，而不是数字本身的安全查找。 99％的情况下，这将是足够的信用卡存储 – 快速和非常安全。
如果你真的需要在某些情况下对信用卡进行可逆encryption（例如继续计费），我会使用存储在数据库以外的安全位置的对称密钥。 我看了一下PCI规范已经有一段时间了，但我相当肯定这是PCI兼容。
如果您需要快速查找以及可逆encryption，请同时使用这两个选项：散列和encryption。
编辑：我的答案似乎有一些争议。 我想指出以下来自Integrity.com的非常有趣的文章（PDF）：
散列信用卡号码：不安全的应用程序实践
它详细介绍了存储信用卡数据散列所涉及的许多问题，但其结论证实了我的build议。
是的，卡的原始散列不安全; 这就是为什么我们用我们的哈希值 但静态盐也不安全，它们允许为已知的静态盐创build彩虹桌。 所以最好让我们的盐以某种不可预知的方式变化。 在密码的情况下，对每个被检查的密码使用单独的随机哈希就足够了。 它甚至可以和散列的密码位于同一个表/行中。 对于信用卡的情况，这应该是相同的 – 信用卡的每个实例被散列的随机盐。 如果信用卡号码是按每笔交易存储的，则为每笔交易分别加盐。
这种方法有利有弊，但它足够安全。 优点是缺乏关键pipe理; salt和hash在那里，并且不需要改变，同时仍然允许对散列进行审计检查; 例如，信用卡哈希是否与这个已知的信用卡号码相匹配？
缺点在搜寻; 无法在多笔交易中有效search特定的信用卡号码。
当然，无论如何，你都会遇到外部encryption的问题。 除非数据库本身是encryption的（只有一些数据库支持），否则你将无法很好地进行search。 即便如此，在数据库甚至表级别encryption也会显着降低search效率。
最近几次我使用信用卡付款，你从来没有真正将CC信息存储在你自己的服务器上。 你让付款网关处理。 你最终得到的是一个交易ID，你可以使用它来validation信用卡是否仍然有效，并有可用的现金量。 然后，一旦你真正包装了他们购买的东西，你会发出一个捕获命令到付款网关。
这种方法大大简化了在一个网站上集成CC付款的过程，因为您所需要知道的只是特定客户的交易ID。 这当然不允许你做亚马逊 – “诀窍”保持您的CC信息一键购物。 如果交易ID遭到破坏，所有可能的用途是提前收取付款，或者完全取消交易（在这种情况下，当您在发货前确认授权仍然有效时，您会发现它）。 这笔交易不能被用来收取比客户已经核准的更大的金额，也不会允许有人收集到与“商店”configuration不同的账户。
也许不是你正在寻找的确切答案，但也许它可以解决您的整体问题，而不必花费在安全供应商的财富。
在某些情况下，encryption密钥不是存储在磁盘上，而是存储在某些硬件设备上。 使用特殊的encryption服务器来执行encryption/解密，或使用存储在硬件encryption狗上的密钥来完成解密。 这样，黑客就不能窃取解密密钥，而不窃取包含密钥的物理设备（因为密钥永远不会离开设备）。
我看到的另一种方法是将encryption的数据存储在与外界没有直接联系的数据库/数据中心（不能破解你无法访问的内容）。 接口服务器作为代理位于networking的“安全”部分和networking的“面向Internet”/“不安全”部分之间。 强制安全的stream量通过这个安全阻塞点漏斗可以使入侵者更难访问安全的数据。
这些都不意味着您的数据是完全安全的，当然。
作为商家，您可以select将CC数据存储在您自己的数据库中，或者将其外包给第三方供应商。
第三方提供商如IPPayments或澳大利亚Westpac等主要银行均符合PCI 1级标准。 对于Web应用程序，您可以select使用支付接受网页（在您的客户工作stream程中的某个地方展示）从您的公司打上品牌。 对于Windows应用程序（例如你公司的CRM应用程序）和经常性支付，他们通常使用他们的API提供令牌服务，即他们接受CC号码，注册并返回一个唯一的令牌，看起来像一个CC号码。 令牌可以安全地存储在您的数据库中，并用于银行的任何进一步交易，批量支付，对账等。 当然，他们最大的问题是每笔交易的运营成本。 对于从一百万客户那里每月获得信用卡支付的公用事业公司而言，交易成本可能很高。
如果您select在您自己的数据库中存储CC号码，那么DESencryption就足够了。 一个更好的select是在Oracle高级安全性或SQLServer提供的数据库中进行透明encryption，即使DBA也不能解密CC编号。 那么对于密钥pipe理，备份，物理安全，networking安全，SSL传输，改变所有服务器设备和防火墙的缺省设置，防病毒，审计，安全摄像机等都有着重大的责任。
首先，如果您处理信用卡号码，则需要符合PCI-DSS规范，一旦存储号码，PCI-DSS规范的所有12个部分将适用于您。 这对于大多数组织来说是一个很大的代价，如果你没有时间，资源和财力，你不应该走存储信用卡号码的道路。
我们在基于Windows的存储信用卡的电子商务系统上获得了PCI-DSS合规性。 它使用了一个256位的AESencryption。 密钥本身使用Windows DPAPI进行encryption，这意味着密钥只能由与encryption密码相同的用户帐户下运行的进程解密。 encryption密钥存储在registry中。
密钥每12个月轮换一次，一个备份密钥副本被存储为A，B，C三部分，并分布在3个USB驱动器上，每个USB驱动器由不同的人员持有。 驱动器1有A + B，驱动器2有B + C，驱动器3有A + C。 所以任何2个驱动器都需要构造一个完整的密钥（A + B + C）。 这种scheme是容忍丢失任何一个驱动器。 关键部件本身使用只有驱动器所有者已知的密码进行encryption。
你的假设，商人必须以某种方式存储卡是不正确的。 商户最有可能在第一次使用该卡时存储从支付处理网关收到的令牌。 令牌唯一标识商家和卡的组合。 随后，您可以从该商家购买商品，而无需再次提供您的卡号。 如果商家的数据库受到威胁，那么令牌对攻击者来说没有什么价值。 他们只对该商家有效，当发现违规时，他们都可以立即取消。
要回答您的具体问题，可以存储磁盘上encryption的信用卡encryption密钥。 密钥encryption密钥可以从服务器启动时必须input的密码派生而来。 可以使用Shamir的秘密分裂scheme，从而需要N份中的k构造将被用作密钥encryption密钥的秘密。 解密的encryption密钥/秘密然后被存储在存储器中。 如果服务器必须重新启动，那么你需要k股。 这当然是一个很大的开销，我所知道的大多数商家都没有实现这个。 然而，它们通常将密钥与encryption数据分开存储以获得一些中间安全性，因此访问一个并不意味着完全访问另一个（尽pipe如此，仍然非常糟糕）。
我删除了原始文章的内容，因为这并没有直接回答问题。 可以这么说，关键的pipe理和正确的encryption是重要的一部分，但仍然是故事的一小部分。
PCI审计员不可能确保一切正确完成。
如果您想消除任何信用卡盗取头痛，使用未存储在数据库中的盐值（除了存储在数据库中的盐值）对它们进行哈希处理。 用任何现代哈希algorithm对它们进行哈希处理几乎可以解决信用卡被盗问题的大部分问题，但这确实意味着消费者在每次购买时都必须重新input信用卡。 在处理存储信用卡号码的项目之后，我发现把他们的安全审查成本降低了一个数量级（这个项目是在PII担忧之前的）。
如果你打算使用对称encryption，那么你进入了一个新的复杂领域，所有这些都涉及到对解密密钥的pipe理和控制。 我会说，即使你散列的信用卡号码，你仍然需要处理可逆encryption，因为所有的个人身份信息（个人身份信息）必须encryption。 SQL Server 2008有一个新的Extensible Key Mangement插件体系结构，它允许使用第三方供应商程序来pipe理对解密密钥（包括拆分密钥）的控制。
更多信息： 部署基于支付卡行业数据安全标准（PCI DSS）1.2版的SQL Server 2008。
任何解密encryption信息的自动化系统将完全不安全。 通过自动化这个过程，你正在击败encryption。 任何encryption的数据只能由用户input的密钥解密。
