上次更新工作进度:01-26-2012 Ken Cochrane著

我三年半前刚开始在CashStar.com公司工作时,曾经听说过PCI,但并不真的知道它的含义。那时我们正在构建一个可以通过网络来接受信用卡交易的商务平台,我发现必须保证我们的平台完全符合PCI规范。由于我们是“第一个吃螃蟹”的人,没有太多的钱,而且所犯的任何一个错误都可能毁了公司,所以我也不想成为其中一个犯错误的人。我花了大量的时间来研究PCI,以及它到底做了什么保证web应用程序足够安全。

我做的第一件事情是先在网络上简单的搜索了一下信息。我惊讶的发现网上真的没有太多可用的信息。而且很多可用的信息也并不使人易于理解,甚至还有点模糊。当然可以请一些公司来指导你走遍整个交易过程。但是既然我们没有太多的钱,所以这对于我们来说也不是一个可选的选择。所以我做了任何极客在这种情况下都会做的事情。当我实现了完全符合PCI规范时,已经竭尽所能的花了大量时间阅读PCI相关资料,并对其进行了研究,终于用自己的方式从PCI这座“地狱”里“越狱”出来。

我贴这篇博客的目的是把自己所有的经验教训写下来,这样就能帮到其他人了解整个过程。同时在将来需要再次使用PCI的时候,它能作为一种提醒,让我回忆起上一次的每个细节。我希望把它弄成一份“鲜活”的的文档。随着时间流逝和情况变化,我将尽力实时更新。如果你注意到某些内容不正确或者有什么遗漏,请发表评论。我将尽全力一有机会就更新。

快速链接

什么是PCI?

为什么要创建PCI?

PCI对我有影响吗?

PCI DSS 要求

PCI通俗解释

如何进行PCI认证工作?

如何开始?

我属于PCI哪个级别?

RoC 或SAQ?

合规报告(RoC)

自我评估调查问卷

PCI成本是多少?

外部审计

PCI 2.0

细节

PCI常见错误

能存储的信用卡数据

令牌标记

数据中心

提供云服务器的主机供应商

安全扫描

入侵检测系统

哈希破解信用卡号码

彩虹表和加盐值

真的需要担心被黑客攻击吗?

如果被黑客攻击了,会发生什么?

如果权益受到侵害,该怎么办?

相关链接

什么是PCI?


大多数人问的第一件事情就是“什么是PCI?”。PCI是“支付卡行业安全标准委员会”(Payment Card Industry Security Standards Council)中的Payment Card Industry简称。它包括American Express、Discover Financial Services、JCB、MasterCard和Visa,于2006年9月7日成立。

建立PCI SSC的主要目的是提供一套通用的可供商户使用的安全标准,使他们能更好的保护自己免于黑客攻击。PCI SSC也提供了支付卡行业数据安全标准(Payment Card Industry Data Security Standard,PCI DSS)。它包含了12种要求和多种子要求。这些商户需要遵照的要求可使他们接受PCI SSC成员的借记卡、信用卡、预付卡、ATM或POS卡交易。

为什么要建立PCI?


  • 建立它是为了对付数据安全漏洞。
  • 指导商户。当涉及持卡人数据交易时,能帮助他们确信他们正在遵照最佳安全实践。

PCI对我有影响吗?


  • 你是否接受信用卡/借记卡的在线支付或电话交易?
  • 信用卡信息是否传送到你的服务器上?
  • 你是否保存信用卡信息?对它加密吗?

如果这些问题你都回答yes,那么PCI至少以一种或其他更多种方式在影响着你。

PCI DSS 要求


这里罗列了PCI DSS 的12种要求。你看完之后,会发现其中有很多种要求并不是那么复杂,并且可能已经在这么做了。其中很多种也仅仅是常识,但依然能让很多不知道的人感到惊奇,即使它们只是常识。

  1. 安装和维护防火墙设置,保护持卡人数据。
  2. 不要使用承包商提供的系统缺省密码和其他安全参数。
  3. 保护已存储的持卡人数据。
  4. 加密传输持卡人数据到公共开放网络。
  5. 使用和常期更新所有普遍受到恶意软件影响的系统上的反病毒软件。
  6. 开发维护安全系统和应用程序。
  7. 禁止访问只有业务人员需要知道的持卡人数据。
  8. 为每个访问计算机的人分配一个独立的ID。
  9. 禁止物理访问持卡人数据。
  10. 追踪监控所有对网络资源和持卡人数据进行的访问。
  11. 常期测试安全系统和交易过程。
  12. 维持一个用来解决信息安全问题的公司政策。

PCI通俗解释


  • 所有商户,无论是否保存了信用卡数据,任何时候都必须做到和保证自身行为符合规范。
  • 商户不能保存特定信用卡信息,包括CVV、追踪数据、磁条或PIN数据。
  • 如果要保存已经过允许可保存的信用卡数据,需要遵照PCI安全标准用一种安全的方式保存。

如何进行PCI认证工作?


可以像下列这样执行PCI认证工作。如果想接受信用卡或借记卡交易,需要同意自己会在任何时候维护PCI认证。有很多方式可以确认是否已被认证。填写一份自我评估调查问卷(Self-Assessment Questionnaire,SAQ),再填写一份合规报告(Report on Compliance,ROC。是所有经受支付卡行业数据安全标准审计的一级Visa商户必须完成的一种表格。——译者注)。我会在之后说明两者之间的细微差异。但其中,需要记住的重要部分是填写一些文件,然后经常发送给请求出具这些文件的人或公司。他们经常是那些办理信用卡和处理商户帐号的公司。

  • 填写一份自我评估调查问卷(SAQ)并知晓自己属于哪个商户级别。
  • 确保遵照该商户级别建议。
  • 修复任何问题。
  • 立证宣誓符合规范(如果正在自我评估中)。
  • 外部审计(如果有需要的话)。

如何开始?


  1. 确认企业组织中有专人负责PCI规范,并组建一支包含来自各个领域成员的团队。
  2. 确定商户级别(1级到4级)。
  3. 确定何种SAQ是企业组织需要完成的。
  4. 评估企业组织是否已尽全力在内部做到符合PCI规范或雇佣了一位认证安全评估专员(Qualified Security Assessor,QSA)。
  5. 雇佣一家获批扫描承包商公司(Approved Scanning Vendor,ASV),开始进行外部IP漏洞扫描工作。
  6. 确保企业组织有一个信息安全政策,并正在强制执行中。
  7. 在评估或扫描工作中,立刻解决任何已发现的明显不足之处。
  8. 保留自我评估、扫描和后续工作记录。准备一有要求就提供这些文件。

我属于PCI哪个级别?


这里有4种PCI规范级别。一年中办理多少笔交易决定你属于哪个级别。

商户级别

级别1: 每年办理600多万笔交易的商户(所有渠道)或被任何Visa地区认证为1级全球商户。

级别2: 每年办理100万到600万笔交易的商户(所有渠道)。

级别3: 每年办理2000到100万笔Visa电子商务交易的商户。

级别4: 每年办理2000笔不到的Visa电子商务交易的商户和所有其他每年办理高达100万笔Visa交易的商户。

要求

级别1:每年执行要求的现场安全评估工作。每季度执行要求的网络漏洞扫描工作。

级别2:商户根据自身情况自行斟酌执行现场安全评估工作。每年填写要求的自我评估调查问卷。每季度执行要求的网络漏洞扫描工作。

级别3:每年填写要求的自我评估调查问卷。每季度执行要求的网络漏洞扫描工作。

级别4:每年填写要求的自我评估调查问卷。每季度执行要求的网络漏洞扫描工作。

RoC或SAQ?


如果你是1级,那么要填写一份RoC。如果你是2、3或4级。那么要填写一份SAQ。这些规则也有例外之处。比如,如果在过去存在过一个安全漏洞,信用卡公司会要求你完成一份RoC,即使你不是1级。

合规报告(RoC)


如果每年办理了600多万张信用卡(1级),会被要求执行一次现场PCI评估工作,并由认证安全评估专员(Qualified Security Assessor,QSA)出具一份合规报告(Report on Compliance,RoC)。其他2级企业组织也会被要求发送一份RoC或自己选择发送RoC以争取成为1级商户。

也可以用QSA提供这样的年度审核。它包括对在PCI规范范围内的网络、服务器和数据库确立的过程和流程进行审核。这些工作包括对企业组织中的相关干系人的面试审核、对支持性文件的审核、对规范计划的验证和完成报告其本身。

QSA常鼓励它们的PCI客户在一整年中使用PCI规范管理解决方案。这会帮助他们保证自己的日常运营情况符合PCI规范;执行现场评估工作;更快更顺畅的完成RoC。

自我评估调查问卷


这里有5种SAQ分类。你属于哪一类将决定文件填写工作是相当简单还是需要花费更长的时间。5种分类如下:

SAQ-A:所有涉及持卡人数据功能的工作都被外包出去,不用出示卡(电子商务或邮件/电话订单)的商户。这不适用于面对面的交易。

SAQ-B:不能存储或只能独立存储而不能在线存储持卡人电子化数据,只能盖印的商户。不能存储持卡人电子化数据,拥有拨号终端的商户。

SAQ-C-VT:只能使用基于网络的虚拟终端,不能存储持卡人电子化数据的商户。

SAQ-C:有连接到网络的支付应用系统,不能存储持卡人电子化数据的商户。

SAQ-D:所有其他不包括上述SAQ分类A到C描述的商户和所有被某支付品牌认为有资格完成SAQ的服务提供商。

既然这里只讨论web应用,所以你极有可能是A、C或D类商户。一旦你知道自己属于哪个分类,则要填写该类的SAQ。一旦完成了此类的SAQ,也要立证宣誓自己行为将会符合规范。

这里有一份很有帮助的指导指南,帮助你知道自己属于哪个分类。

SAQ-A

A类中有很多不尽相同的部分,但其中最重要的一部分是不能让信用卡数据和你的服务器发生关系。做到这点最简单的方法是当你要人们输入信用卡数据时候,重定向这些数据到其他第三方公司的服务器上。贝宝(Paypal)、谷歌网络支付(google checkout)和亚马逊支付(Amazon payments)普遍都这么做。

另外一种实现这点的方法是让信用卡网关host支付网页。这样做的一个例子是authorize.net公司的Simple Checkout

第三种实现这点的方法是所谓的“transparent redirect”或“Direct Post”方法。BrainTreePayments 公司是第一家用这种流行方法实现这点的公司,但之后Authorize.net公司也增加了这种方法,作为第二种方法的一个替代方案。

最后还有一种方法,基本上和第三种方法很类似。但它是用javascript来加密信用卡数据,并将数据发送给信用卡数据处理器,然后用唯一的令牌填入表单以供之后使用。这种方法stripe公司正在用。 BrainTree和livingsocial公司将这种新方法称之为端对端信用卡数据加密法(端对端即点对点的两端电脑的直接连结——译者注)。

SAQ-C

如果你正在host支付表单到服务器,点击表单中的提交按钮,传送表单数据到服务器,然后解析表单数据,将信用卡细节数据从表单字段里抽取出来,建立自己的web请求,并在之后将它发送到自己的信用卡数据处理器中,那么此时你至少是个C类商户。即使你不打算存储数据,因为信用卡数据也可用于计算机内存中并且你的代码正在和它打交道,所以这里极有可能会发生某些风险并且能够获取对它的访问权。

SAQ-D

如果你不属于其他种类商户,那肯定是D类商户了。SAQ D有时候也被称为“轻量级”ROC,因为任何属于SAQ D类商户的企业组织尽管其规模不大,但它们也基本上通过了所有12种PCI DSS要求。

PCI成本是多少?


这真的很难为此得到一个精确值,因为它对每家商户来说都会不同。但是可依据这篇BrainTree公司的文章“how much it costs to become PCI Compliant”中的一张表格来估算:

说明

外部审计


说明

如果你的公司够大或够不幸到需要外部审计,这可不便宜啊。审计工作会持续好几周或需要更多的在现场工作。请低端审计公司审计也要花费2万到3万美金,普通公司大约是一年22.5万美金,如果是排名前10%的审计公司则要花费50多万美金。正如你所见,每年这样花费的成本真的很昂贵,所以应该尽可能的避免。

这里也重要的指出一点:这些成本只是审计工作本身所花费的成本。如果审计公司在审计中发现任何错误,你需要在他们认为你审计合格之前支付花在修复任何审计问题上的成本。

这里有一些链接,我是从它们那里得到数据的。

PCI 2.0


在2010年10月26日,PCI DSS 发布了版本2.0。这里有一些需要强调的。

  • 132处更新,2处新增,其余的都是澄清说明和附加准则。
  • 增加了更多有关虚拟化的准则和它们对PCI的影响。
  • 亚马逊网络服务中心(Amazon web services,AWS)现在是符合PCI 1级规范的数据中心。

细节


既然已经知道了所有一切有关PCI的知识,那么就让我们深入细节吧。我被问到的最常见问题是“有什么最简单的方法称为PCI认证商户?”。这里就有我可以告诉大家的。

第一道关卡是如果要帮客户使用信用卡做交易,应避免处理客户的信用卡数据。今后随着Braintree和stripe这样的公司出现,这会变得非常容易。在可以用这些解决方案之前的很多年,唯一能做到这点的方法是用丑陋的支付网页host信用卡网关,但是这不能很好的集成,也能难集成应用程序,所以很多人并不用这个方法。

现在没有任何借口了,让信用卡处理器处理所有信用卡数据吧,这会让生活更加轻松。如果想知道有多轻松,请访问PCI security standards官网,下载SAQ A SAQ C文档。你会发现SAQ A非常容易,让你少了很多麻烦。

虽然Briantree和stripe公司的解决方案很牛,但它们不能解决所有问题。近年来,随着手机应用程序的使用越来越普遍,如何通过API来接收信用卡数据已成为了一个常见问题。如果基于某些理由不能使用其他解决方案中的办法,可以使用Akamai公司的Edge Tokenization,它不仅适用于API,也适用于基于网络支付的表单。虽然很昂贵,但是如果已经使用了Akamai公司其他一些解决方案,那么这对你来说也不是个大问题。

如果看完上述所说的所有办法之后,依旧需要/想要通过自己的服务器来验收信用卡数据,那么你需要知道一些其它事情。比如,下列这份大多数人都会犯的常见错误列表。

PCI常见错误


这里有一份大多数人都会犯的常见错误列表。之所以在这里罗列它们,只是为了在还不是太晚的时候让你能够意识到这些错误,如果遗漏了什么,请联系我让我知晓。

在空白文本中存储信用卡信息

理想化情况下,不应该存储信用卡信息。但是如果不得不这么做,应该常常加密数据。这样如果有人拿到了数据,他们也只有花更多精力才能看到数据。

没有改掉缺省密码

我经常对此感到惊讶:人们所使用的密码安全性非常低而且很多次开始登录时,大家依旧在使用第一次给他们时的密码。那就是为什么要一次性生成一个密码并确保它安全。这样的话,如果人们不更改被告知的密码,至少在刚开始时候,这个密码是安全的。

如今在市场上真的有很多相当不错的密码管理工具,我可以推荐其中的一个。我喜欢用的一个是1password

从服务器上去除所有不需要的程序

有很多理由可以告诉你:为什么要在不想使用计算机上的程序/软件时,去除它们。第一个理由是:它们会使计算机空间变少,而且即使没有运行它们也会占据处理器和RAM空间。一个运行更快的系统总是好的。第二个理由是:可以不必维护那些不想使用的软件程序安全补丁。这样的话,当拿来一台新的在线服务器时,首先要做的是去除所有不想用的东西,如果后来想用,可以在之后再把它们加回到系统中去。

使用防火墙

应该经常使用防火墙。只要使用它并从不关闭它,不管是硬件防火墙还是软件防火墙都无所谓。在我的某些生产系统中,我运行一个硬件防火墙来保护我的私人网络,同时又在每个系统上运行一个软件防火墙。某些人会认为这样做是多此一举,但我宁愿更加安全点,也比出了事情才遗憾要好。

运行防火墙只是其中一部分,还要知道如何和为什么安装防火墙。也应该经常记录端口开启情况,并知道为什么要开启。这在之后审计时,审计人员想知道哪个端口开着,以及开这个端口的理由是什么的时候,会非常有帮助。

应该每季度对防火墙进行一次审查,确保它们和所记录的情况一致,并要清楚任何以前开启过的端口是否依旧需要开启。随着时间流逝、系统发生变化或某些时候要去除某个不再需要的服务时,你也需要关闭端口。

也可以使用像CloudFlare这样的服务,来保护网站免于一系列诸如垃圾邮件发送、SQL注入和DDOS这样的在线攻击,这很容易安装,而且要尽量使你的代码变更最小化。

编写劣质网站代码

如果正在编写Web应用程序代码的程序员们很粗心大意,并且不知道他们自己正在干嘛,他们可能会写出导致SQL注入和其他弱点的糟糕代码。

跨站点脚本攻击(Cross Site Scripting,XSS)如今正在成为一种越来越普遍使用的攻击网站方法,所以对此你也要小心点。

要保证经常执行代码审查工作,并在将代码投入生产环境之前,对应用程序进行渗透测试/(渗透测试,Penetration Testing。作为网络安全服务体系中的一种新技术,是在实际网络环境下,由高素质的测试人员发起的,经过授权的高级安全检测行为。——译者注)

缺少监控和日志记录

令人惊讶的是很多公司并不监控自己的系统或应用程序,这就如同他们正在闭着眼睛跑步一样,当情况正在变的糟糕时,他们根本没有意识到糟糕情况发生,直到客户告诉他们才意识到。应该尽可能地进行更多的监控和日志记录工作,这样就能在任何时候知道任何系统上正在发生的事情。如果系统运行良好时,不做日志记录,那么当某些情况开始变的糟糕时,你不会意识到这些看似和它们良好时一样的糟糕情况。 这里有一份工具列表能帮助你进行日志记录和监控。

  • Pingdom是个网站监控工具。当站点出问题的时候,能告知一切情况。
  • Nagios提供完整的服务器、交换机、应用程序和服务监控提醒。
  • Cacti是套完整的网络图形化解决方案。被设计成用来驾驭RRDTool数据存储和图形化功能的强大威力。
  • Sentry开源实时记录事件日志的聚合平台。
  • Loggly日志管理云服务端,集中化的记录搜索分析、时间序列数据日志。
  • graphite可扩展的实时图形化服务器。
  • collectd是个间歇性收集系统性能统计资料的后台程序,并用多种方式提供值存储机制,如RRD文件。
  • monit可简单和积极主动的监控Linux/Unix系统、网络和云服务器。
  • muninMunin是个有助于分析资源趋势的网络资源监控工具。
  • New Relic是唯一一个可以精确定位和解决Ruby、Java、.NET、PHP和Python应用程序性能问题的工具。
  • Pager Duty为Nagios、Zenoss、Munin、Monit和更多其他IT监控工具进行电话&短信提醒和待命安排。

缺少安全补丁

定期安排在所有的系统上安装所有安全补丁,对你来说非常重要。一个看似没道理但令人惊讶的现象是很多人或公司并不这样做。

也应该为任何正在使用的产品订阅所有安全提醒电子邮件列表。同时也要注意下列网站。一旦收到某个潜在问题通知,就能在它影响你之前修复它。

  • http://www.us-cert.gov/cas/
  • http://seclists.org/
  • http://www.sans.org/newsletters/

在支付页面没有使用SSL

这是另外一个没道理但时不时发生的现象,应该在web应用程序里添加代码来检查SSL是否已保证服务于支付页面。如果不是,请重定向到有SSL版本的页面。

做到这点的一个简单方式是:让SSL在任何时候都服务于整个站点,然后把web服务器80(http)端口简单的重定向到443(https)端口。这就能保证在任何时候所有的数据传输情况都能被SSL服务。

记录支付信息日志

我所见到的最常见错误之一是:某些人设置他们的日志管理工具能把支付表单中的数据打印到日志文件中去。出于调试目的这是非常好的,但是对PCI来说却很糟糕。应该经常在记录请求日志之前,把重要的信息从请求中剥离出去。也可以把信用卡卡号替换成*号加后4位号码来达到同样的调试结果。

另外一个与之相似的常见错误是:当发生某个错误,email给开发人员时,把所有的数据都发给他们。如果你也这么做,首先要确保已剥离了信用卡信息,否则某人的信用卡信息说不定现在已经被email发送到全世界各地了,这完全是不对的啊。

能存储的信用卡数据


很重要的一点是永远不存储信用卡数据到数据库中,即使已加密数据。很不值得为此被麻烦、冒风险和花费处理外部审计的成本。但如果一定要坚持这么做,这里有一些需要知道的事情。

如果基于某些理由,对我的建议置若罔闻,并且不管如何都要存储信用卡数据。这里有张小图显示了哪些数据可以被存储。而不管它是否被加密。 enter image description here

  • 根据3.3:显示时掩盖卡号(信用卡卡号头6位和后4位号码是最多可显示的号码)。这意味着可以像*****1234 Visa那样替换真实的信用卡卡号。如今这样做非常普遍。
  • 根据3.4:使用下列任何一种方法,使卡号不管被存储到哪里,都不可读:(包括便携式数字媒介设备、备份媒介设备和日志文件)
    • 基于强密码方式的单向哈希法(必需哈希整个卡号)[可使用诸如安全哈希算法(Secure Hash Algorithm,SHA)这样基于强密码方式的单向哈希函数,使持卡人数据不可读。哈希函数不需要检索原始卡号号码(因为单向哈希法是个不可逆的过程)。为了创建复杂的彩虹表(彩虹表就是一个庞大的、针对各种可能的字母组合预先计算好的哈希值的集合——译者注),推荐但不强制要求在卡号之外还输入一个加盐值(来源于MD5算法。因为MD5算法本身是不可逆的,为了加强MD5的安全性从而加入的新的算法部分即加盐值——译者注)到哈希函数中去。]
    • 截值法(哈希法不能用来替换卡号被截断的部分)。
    • 索引令牌和pad值(必需安全存储pad值)。
    • 使用强加密有关键值管理的过程和流程的方法。

令牌标记


如果要存储信用卡信息,最好的方法是使用令牌标记(tokenization)服务来代替自己存储信息。把信用卡信息存储到他们的系统中去。他们会给你一个唯一的令牌以供在未来交易中用它代替信用卡进行交易。如今这种类型的服务也非常普遍,只需问你的信用卡发卡商是否也有这样的服务就行。这里有一些提供这种类型服务的信用卡发卡商公司信息。

数据中心


当遵照PCI规范进行交易时,需要担心全部东西。不仅是应用程序,也有安装应用程序的服务器、服务器连接的网络和服务器所“居住”的数据中心。首先要做的事情是联系主机提供商了解他们是否遵照PCI规范。如果他们是的话,要向他们要一份有你的记录情况的PCI文件拷贝(之后或许会需要)。主机提供商们经常在他们的官网网页上“吹嘘”自己遵照PCI规范,所以这常常也是一个好的开始。

主机提供商公司规模越小,则遵照PCI规范进行交易的可能性越小。如果你只参与了一个共享主机计划,每个月只需付20美金,那么极有可能没有遵照PCI规范。或许你运气好,但是我对此很怀疑。如果主机提供商公司是PAAS或是一家云服务器提供商公司,那你也极有可能没那么幸运了。

提供云服务器的主机供应商


亚马逊网络服务中心(AWS)最近已经让他们的数据中心满足了PCI规范,但需要重点注意的是仅仅因为数据中心遵照规范并不说明你的应用程序也是这样。如果你把应用程序放在EC2,接受那些EC2实例所处理的信用卡数据,那么需要确保除了其他东西之外,还有个入侵检测系统(Intrusion Detection System,IDS)(入侵检测系统是一种对网络传输进行即时监视,在发现可疑传输时发出警报或者采取主动反应措施的网络安全设备——译者注)。所有好的IDS系统都是基于硬件的。并且有专人在任何时候监控数据传输情况。在AWS不能安装这些系统,所以需要依赖一套基于解决方案的软件,而这并不好,并且对网络增加了额外的复杂性。

RackSpace公司提供hybrid cloud hosting配置服务,能让你有硬件防火墙、IDS、负载均衡、云网络服务器和硬件数据库服务器。但是即使这样的配置服务,也没有遵照PCI规范,至少我还不能让RackSpace告诉我它遵照了PCI规范。

其他云服务器供应商可能会提供一套完整的符合PCI规范的解决方案,但我猜他们会让你花更多的钱。如果你知道有这么一家,请让我知晓。我会把这家公司信息更新到这里。Terremark公司极有可能就是这么一家公司。

安全扫描


PCI认证中的一个关键部分是要求有第三方安全扫描公司。基本上,你不得不请一家已获得认证或批准的安全扫描公司定期扫描网络、服务器和应用程序,如果他们发现任何问题,你需要修复这些问题,修复之后他们会再次扫描,直到已通过扫描。一旦通过,他们会给你一份认证合格证书,你可以把它加入到你的PCI文件中去。

以前我曾经请过一家叫ControlScan的公司,也请过Qualys公司。但我相信还有很多其他这样的公司。请为你挑选一家看起来最好的公司。这里是一个链接PCI approved scanning vendors,罗列了一份PCI获批扫描承包商公司信息列表。

入侵检测系统


入侵检测系统(IDS)基本上位于网络前端,观察所有进入网络的数据传输情况。这看起来,如果它发现有任何异常情况或有人尝试使用已知网络攻击手段攻击网络和其它某些情况,它都会让你知道。这些系统都有基于解决方案的硬件和软件。价格也从免费到一个月上千美金不等。互相之间也各有不同特点和功能,所以最好挑一个你需要的,并易于维护的系统。

我曾用过AlertLogic公司基于IDS的硬件,效果蛮好的。这个公司有一群随时待命专门监控设备的员工。如果有什么事情发生,他们会去检查设备并根据情况采取相应措施。

哈希破解信用卡号码


这里有个很好的例子说明为什么哈希破解信用卡号码不是个好主意。我正在浏览下列这两个连接中的有关内容,

仅仅因为遵照了PCI规则并不意味着万事无忧,你依旧不得不运用常识。

PCI DSS 3.4小节[pdf]: 使用以下任何一种方法,使卡号不管被最小程度的存储到哪里,都不可读:强单向哈希函数(哈希索引)。 使用以下任何一种方法验证数据已不可读:如SHA-1这样的单向哈希法(哈希索引)。

基本大意是你可以存储信用卡卡号头6位号码(BIN),也可存储信用卡卡号后4位号码。信用卡卡号长度介于13到16位,最后1位号码是校验位(Luhn 校验算法)。

让我们看看,破解出这张卡号为4012888888881881的信用卡卡号号码有多难。

如果我们不知道这张卡的任何信息,从全16位开始算,即有10的16次方(10^16)或10,000,000,000,000,000(10千兆)种可能的卡号号码。

既然正在存储信用卡类型,我们知道这是张visa卡。所有Visa信用卡都是以“4”开头的。这意味着可能是4XXXXXXXXXXXXXXX或有4,000,000,000,000,000(4千兆)种可能的卡号号码。只减除了一半以上可能的卡号号码。

如果我们能存储bin(卡号前6位号码)和后4位号码,那么会是这样的:401288******1881或1,000,000(100万)种可能的卡号号码。

开始写一个简单的破解程序来试试运气。(程序用Ruby编写) enter image description here

代码 enter image description here 运行一下 enter image description here

如果只是使用SHA-1哈希法,这段程序用了5.3秒就破解了哈希码。可以使它破解的更快,只要在运行哈希法之前,对卡号号码做一次luhn校验。如果luhn校验失败,那么就知道卡号号码无效了,也就没必要运行哈希法了。既然哈希函数运行的比luhn校验慢,这就说明luhn校验能加快运行速度。

彩虹表和加盐值


由于信用卡卡号号码是个有限的数字,那么可以预先计算出10千兆种可能的卡号号码中的每个值它的哈希码,然后将这些哈希码存储在一个可查询的表格中。当需要破解某张信用卡卡号哈希码的时候,所有需要做的事情就是查到该张信用卡卡号哈希码,这样就能很快的破解出这张卡卡号。像这样存储所有已知值的表格叫做彩虹表(Rainbow table)。

理想情况下,如果想哈希破解某张信用卡,不要使用SHA-1或MD5方法,而是使用SHA更新版本的方法:SHA-256或再之上的版本方法。同时也要使用加盐值(salt)。加盐值基本上是哈希破解时经常使用的第二唯一值,通常只要得到信用卡号码就能生成一个不同的加盐值。

既然生成彩虹表时,没有加盐值,彩虹表就不管用。这就增加了额外的安全性。确保加盐值不被丢失,否则不得不重头再来。把加盐值看作密码并保证它安全。

真的需要担心被黑客攻击吗?


这里有一份最近受到黑客攻击的公司信息简单列表。如果他们都能被黑客攻击,那么你呢?

如果被黑客攻击了,会发生什么?


  • 被禁止接受信用卡交易。
  • 名誉损失和顾客流失。
  • 每次事故高达50万美金的罚款。
  • 法律问题(可能会受到控告)。

如果权益受到侵害,该怎么办?


在发生安全事故的事件中,商户必需采取以下紧急措施:

  1. 控制和限制信息曝光。对24小时内有怀疑或已确认会危及账户信息的损失或劫持,进行彻底的调查。
  2. 提醒所有有必要提醒的各方机构。要确认提醒:
    • 商户帐号提供商。
    • Visa金融欺诈控制小组。电话:(650) 432-2978
    • FBI本地办公室。
    • U.S.秘密服务机构(如果已危及Visa支付数据)。
  3. 24小时内,向Visa金融欺诈控制小组提供被危及的Visa账户信息。
  4. 在报告危害后的4个工作日之内,向Visa提供一份事故报告。

相关链接:


Akamai edge tokenization

PCI Security Standards

American Express PCI pages

Discover Financial Services PCI pages

JCB International PCI pages

MasterCard Worldwide PCI pages

Visa Inc PCI pages

Visa Europe PCI pages

原文来自: http://kencochrane.net/blog/2012/01/developers-guide-to-pci-compliant-web-applications/

The Developers Guide to PCI Compliant Web applications

iTran乐译

iTran乐译参加活动,读好文章!