安全观察密码和信用卡，第 2 部分
Jesper M. Johansson
内容
伪多因素登录过程
浏览器加载项问题
认证标记永远不能改变
降级到低安全性密码
忽略伪多因素登录
密码被破坏问题
一些好处
通过表面假象误导用户
打开还是不打开
提供安全通信
关于隐私
在这个由三部分构成的系列文章中，介绍了 IT 行业在安全性问题方面是如何给消费者带来困惑而不是为他们带来帮助的，您现在阅读的是其中的第二部分。在 2008 年 7 月刊的《TechNet 杂志》中，我介绍了不可行和不正确的安全建议以及一些令人困惑的登录工作流。（如果您尚未阅读第 1 部分，可在以下地址找到它：
technet.microsoft.com/magazine/cc626076。）在文中我阐述了我的观点，指出那些虽然相当常见但又糟糕之极的安全建议和登录工作流是如何给消费者带来困惑并削弱他们在保护个人信息方面所做的努力的。
在这一部分中，我将通过一些取自消费者安全领域的真实示例继续展开讨论。本系列文章的最后一部分将在下一期的《TechNet 杂志》中推出**，其中会包括针对全球安全问题专业人员提出的倡议。
伪多因素登录过程
2005 年 10 月，美国联邦金融机构监管委员会 (FFIEC) 颁布了“网上银行环境中的身份验证”指导原则（请参阅 www.ffiec.gov/press/pr101205.htm）。实施期限只有 14 个月，因此美国的各金融机构很快就着手研究如何满足这些新的指导原则。
大多数机构都无法满足这一时间要求。许多机构虽然最终确实满足了这些指导原则，但他们所采取的措施只是为了满足这些指导原则，此外再无其他用途。换句话说，这些机构所采取的措施根本无法使客户更加安全，他们只是在进行“安全性表演”而已。其中一些最有趣的无用解决方案示例就是试图创建实际上并不具有多因素的多因素身份验证解决方案。
例如当用户键入密码时测量键入节奏的技术。在网站上使用时，此解决方案所显示的登录对话框外观与旧的登录对话框完全相同。但是，此对话框现在是一个 Adobe Flash 对象。
这个 Flash 对象会记录用户的键入节奏，包括按键的时长和两次键入操作之间的间隔等特征。此数据将与密码一起提交到网站，并与其中存储的值进行比较。键入节奏数据必须处于所存储数据的特定方差范围内，并且密码也要匹配，这样才可以成功登录。大致的想法是这样做可以允许站点使用伪生物身份验证方法，而又无需在客户端安装第三方硬件。
我将其称为伪多因素身份验证。它并不是真正的多因素身份验证方法，真正的多因素身份验证要测量两个或更多个以下规范因素：
- 用户持有的证件（如智能卡）
- 用户知道的信息（如密码）
- 用户特有的标记（如指纹）
伪多因素身份验证在身份验证过程中实际上并未包括多个因素，它只是从一个因素（即密码）读取多个参数。然后，它使用这些额外参数来推断用户的身份。
伪多因素身份验证所采用的技术有许多缺陷。这些缺陷集合在一起，导致该技术根本就不可能解决它想要解决的安全性问题。
浏览器加载项问题
伪多因素身份验证系统依靠浏览器加载项来提供所需的复杂客户端处理。所有软件不可避免地都存在着错误，有些错误可能会导致出现漏洞。当软件难以更新且用户不确定是否已安装更新时，这些漏洞就会变成实实在在的问题。
浏览器加载项恰好是导致这两个因素的罪魁祸首 — 它们难以更新并且没有向用户提供足够的信息来指明所安装版本是否已是最新版本。结果导致用户必须向 Internet 公开本来可能并不需要公开的软件片段。
在某些情况下，要使加载项始终保持最新，需要定期访问该加载项的网站以获取更新。毫无疑问，对大多数用户而言这都是不太可能做到的。任何系统如果要求最终用户向 Internet 公开额外的不相关软件而仅仅是为了提供安全性功能，则有必要对其进行重点审视。
认证标记永远不能改变
对于“您特有的标记”这一因素，它具有一个并不会左右其他两个因素的特征（或者说是缺点）。您可以更改密码（您知道的信息）并且可以制造新的安全令牌（您持有的证件），但您可以使用的生物认证标记其数量却非常有限。以指纹为例，您一生中通常只能有十个认证标记。如果意外丢失了其中一个，通常是无法更换的。
现在看一看它是如何应用到伪多因素登录示例的。作为其他因素的一部分而收集的指标无法方便地进行更换或修改。毫无疑问，密码改变时，用户键入的方式会改变，但在键盘上按键时的常规方式却不会改变。这正是此方法赖以存在的基础。如果这些指标遭到破坏，完全可能重新合成它们。最起码，攻击者可以捕获这些指标并重放。
降级到低安全性密码
使用长密码并经常更改密码是一个好办法。并且，正如在本系列文章的第 1 部分介绍的，记录密码（当然是以一种安全的方式）也是一种比较好的做法（这与某些建议相左）。但是，上述方案并没有做到有助于手动键入密码。长密码通常难以键入，如果可以复制和粘贴密码，则记录的密码会更加有用。如果维护上百甚至更多密码，其中一个好方法是使用 Password Safe（网址为 sourceforge.net/projects/passwordsafe）之类的软件实用程序。通过使用此类工具，您可以生成完全随机的密码、以加密格式将其存储下来并可以直接将其粘贴到登录对话框中。实际上，在使用此类工具时，您甚至不必知道密码究竟是什么。
但难题是：无法测量键入节奏，除非用户手动键入密码。而且如果必须将密码键入测量键入节奏的对象中，则这一用来管理密码的方法会无法继续工作。正确键入包含 15 个字符且完全随机的密码并非易事。因此，在面对此类系统时，用户通常会选择简化密码。然而，一个包含 15 个字符且完全随机的密码本身要远比较短的密码与伪多因素身份验证系统相结合更加安全。
实际上，以排他方式实施的伪多因素身份验证方法会迫使用户采用低安全性的密码。不幸的是，正如您稍后将看到的，使那些使用适当密码管理方法的用户迁就伪多因素身份验证系统，会在实际当中消除它所能提供的全部价值。
忽略伪多因素登录
即使站点的确实施了伪多因素身份验证，它仍然必须支持忽略伪多因素系统的方法。首先，很少有站点会要求所有用户都必须在安装“第四方”技术后才能进行访问。部分用户（例如《TechNet 杂志》**的一些作者）一直拒绝安装此类软件。
其次，键入节奏可能会由于多种原因而发生改变，因此站点必须能够适应这一点。例如某个用户因手腕扭伤而导致键入节奏临时发生了改变。如果站点分析了她的节奏后认为是其他人正试图使用她的用户凭据来登录，那么她该如何访问此站点呢？如果损伤是永久性的，用户可以重设存储的节奏值。但如果是临时损伤，假设她的键入节奏很快就可以恢复，用户可能并不希望重设存储值。
最后，并非所有用户都能够使用伪多因素身份验证系统。例如，通过语音识别界面与计算机交互的残障人士可能无法填写对话框（具体要取决于它是否允许编程输入）。此时，法律可能会强制要求提供可满足残障人士需要的备用系统。
满足所有情形的最简单而又最直接的方法是同时支持标准的基于密码的身份验证。
密码被破坏问题
伪多因素身份验证系统声称能够解决与基于密码的身份验证相关的各种问题。但是，这些系统无法完全解决可能会使密码被破坏的各种主要方法。有五种主要方法可能会使在依靠基于密码的身份验证系统中密码被破坏，在这里“被破坏”表示攻击者已获得并使用其他用户的密码：
- 密码猜测
- 击键记录器
- 网页仿冒攻击
- 询问用户
- 侵入存储密码或其哈希值的系统
密码猜测已经不再是特别常见的攻击方法了，由于击键记录器和网页仿冒的出现它已变得相形见绌。密码猜测也是唯一由于伪多因素身份验证的出现而有所减少的攻击方法。传统的密码猜测方法不太可能适用于伪多因素身份验证系统，因为攻击者必须同时猜测密码和键入节奏。尽管从理论上说可以合成键入指标，但通常没有这样做的必要，因为可改用网页仿冒攻击或击键记录器来捕获实际数据。此外，如果系统还提供标准的仅密码登录界面，则攻击者可以使用该系统来猜测密码。
强密码可以有效地杜绝密码猜测攻击。如果可以说服用户使用更强的密码，或者再加上工具的帮助，则根本无需使用伪多因素身份验证。（相比而言，由于伪多因素身份验证系统使用的密码通常较为简单，因此客观上使密码猜测成为一种更可行的方法。）因此，任何旨在提供减少可能的密码猜测攻击的方法，只有在取消了对仅密码登录支持的情况下才能真正发挥作用。并且正如我所指出的，这种情况即使可能也非常罕见。换句话说，如果用户在伪多因素身份验证系统中使用较弱的密码，密码猜测可能会再次成为一种可行的攻击方法；这会导致伪多因素身份验证不但不能增强安全性，反而会降低安全性。对此问题需要进行更深入的研究。
伪多因素身份验证也无法解决击键记录器问题。尽管我并不清楚目前常见的击键记录器能否捕获键入节奏，但肯定不存在能够迫使人们不设计此程序的原因。击键记录器是键盘和计算机之间用来捕获击键内容的一个硬件或一款软件。在这两种情况下，记录器均对伪多因素身份验证解决方案使用的所有数据具有完全访问权限。
实际上，击键记录器甚至可以访问更多的数据，因为身份验证解决方案是以用户模式运行的，而击键记录器要远在它之下。如果在键盘与用来捕获密码的基于 Web 的对象之间没有受信任路径，则不可能防止此类攻击。如果伪多因素身份验证解决方案变得十分常见的话，肯定有人会设计此类击键记录器。
同样，伪多因素身份验证也无法解决网页仿冒攻击问题。攻击者可能会使用一个 Flash 对象来捕获密码以及键入节奏，而不是只使用一个伪造的登录屏幕。
当然，如果攻击者所使用的方法只能获取用户的密码，则伪多因素身份验证确实可以起到作用。例如，从用户获取密码的最简单方式是询问用户。令人震惊的是，无论是当面、通过电话还是通过网页仿冒邮件进行询问，这都被证实是一种非常有效的方式。
当然，询问用户的键入节奏是不太可能的。同样，如果公司密码数据库遭到破坏，则攻击者只可能会窃取密码。但是同样，只有当系统不提供标准的仅密码身份验证时，才可以减少此类攻击。
还应指出的是，如果密码数据库本身已遭到破坏，则攻击者可以采用更深入的方式来破坏系统，而不仅仅是使用单个（或即使多个）常规的用户帐户密码那样简单。因此，试图减轻侵入了密码数据库的攻击者所能实施的破坏并不会起到明显效果。
一些好处
平心而论，伪多因素身份验证确实有助于解决一些问题（假定系统不提供标准的仅密码登录选项）。例如，它可用于防止密码共享。但是，如果系统允许多个用户共享帐户（例如联合银行帐户），则这可能会成为系统的一个缺陷。
此外，正确构建的交互登录对话框（不是网站登录）在用户键入节奏不匹配时可能会强制其执行其他身份验证步骤。这可以为高敏感环境中的被破坏帐户提供额外的安全性。
通过表面假象误导用户
迷惑用户的一个最好办法就是提供不准确的安全指示。最常见的可能是网页上显示的挂锁图像，如图 1 所示。此页面甚至在挂锁旁显示了“安全”一词。
图 1 挂锁图标被滥用的一个示例，此趋势有点令人担忧（单击图像可查看大图）
您肯定知道，仅在页面上放置一个挂锁图像和“安全”一词并不能保证它的安全。但是这种现象却极其常见，甚至一些著名的专门网站也是如此。结果许多用户都养成了习惯，他们只是在网页中查找这些视觉上的安全符号，而不是查看这些符号真正能够代表某种意义的位置：在地址栏中。（W3C Web Security Context Wiki 中有一条有关此问题的说明，网址为 w3.org/2006/WSC/wiki/PadlockIconMisuse。）
不幸的是，仍存在许多类似的滥用示例。研究表明，用户根本无法识别恶意网站，即使是在证书非常明显的情况下（请参阅 www.usablesecurity.org/papers/jackson.pdf）。这取决于轻松辨别真伪的能力，即使是在没有真品可供比较的情况下。这需要一定的技巧，但网页上华而不实的安全误导内容阻碍了该技巧的发展，因为用户都被错误信息吸引过去了。
图 2 显示了有关此问题特别麻烦的一种变体。在这种情况下，显示信息的页面实际上并不安全。如果看一下地址栏，您会看到表明协议的 "http"。此站点使用了一种非常常见的优化技术 — 只加密表单提交，而不加密包含登录表单的页面。就像页面所声明的那样，登录是安全的，前提是要把“安全”等同于“加密”。但是至关重要的一点是，用户在发送凭据之前无法确认其发送目的地！此站点在提交表单之前并不向用户显示验证站点的证书。这是一场信任游戏，就像您在向后倾倒时认为后面的人会接住您一样。等到提交表单的时候，可能已经造成了损害。
图 2 不安全页面上的安全性假象（单击图像可查看大图）
安全套接字层 (SSL) 是在 HTTPS 中提供安全性的协议，主要有两个目的。首先，它为用户验证服务器。其次，它提供一个简单的机制来协商可以在客户端和服务器之间使用的会话加密密钥。
如果只加密实际的表单提交，则并未满足第一个（也是最重要的一个）目标。使用此优化技术的站点只是将 SSL 用作协商密钥的一种方法。令人啼笑皆非的是，只需使用标准的密钥协商协议就可以实现此目的，这样还可以避免因使用 SSL 所带来的成本和开销。
图 2 所示的站点并不罕见。许多站点仅为表单提交而不是为表单本身提供 SSL 保护。但是，这个特定站点有一个让人非常头疼的特点。如果在浏览器地址栏中键入 https://www.<site>.com（请注意安全 https 指示符），站点会将您重定向到非 SSL 版本的站点！即使尝试在向站点发送凭据之前先检查证书，站点还是会拒绝显示证书。
虽然并非所有站点都这么差劲，但这样的站点也不少。美国两家最大的信用卡发行公司都有此类问题。实际上，在我打过交道的三家主要信用卡公司中，只有美国运通公司对登录表单提供了证书。美国运通甚至将 HTTP 请求重定向到了 HTTPS。做得不错！
最后一个想法是与毫无意义的安全假象以及缺少登录表单证书有关的。您可能想知道为什么站点要这么做。原因很简单，可以从经济学方面加以解释。呈现证书需要加密页面，而加密页面会增加处理开销。处理开销意味着提供相同负载需要更多的计算机。计算机越多，成本就会更高。不幸的是，当需要在保护客户隐私和增加利润之间做出选择时，许多组织都会选择增加利润。
打开还是不打开
最近，我从健康保险公司处收到了一封令人惊讶的电子邮件。使用计算机超过 10 年的人都知道不应打开一个未经请求的电子邮件附件。所以可以想见我收到图 3 所示的邮件时有多么吃惊。
图 3 包含“安全附件”的电子邮件（单击图像可查看大图）
显然，我曾在健康保险公司的网站上提出过问题（直到收到这封可疑邮件我才想起是有这么一回事）。以下是该公司的答复。刚开始我以为这是一个聪明的网页仿冒欺诈。当我意识到这是一封合法的邮件时，我脖子后面的汗毛都竖起来了。
在邮件开头指示用户双击附件开始解密邮件。安全性社区和 IT 管理员花了近 10 年的时间来教会人们千万不要双击附件。然后一个公司跳了出来（顺便提一句，我的医疗保健提供商并不是使用这种方法的唯一组织）说我必须双击附件才能实现安全性。这时用户该怎么办？他应该记住或忘记哪种行为？
接下来，我使用 Microsoft® Office Outlook® 2007 中的预览功能进行查看。如图 4 所示，Outlook 认为该邮件可能是攻击邮件，警告我不要打开它！
图 4 Outlook 2007 认为该安全文档是恶意的（单击图像可查看大图）
对于健康保险公司违反全球最流行的电子邮件客户端所使用的基本安全检查这一点，让人觉得既是个讽刺又令人感到悲哀。鉴于此家公司甚至没有专门通过 Outlook 来测试新的安全性解决方案，我迫切想知道它采取了其他哪些措施来保护我的隐私信息。或者更坦率一点，我想知道它究竟实施了哪些其他解决方案来避免由于未能充分保护客户隐私而受到指控？这一点类似于财务机构所做的安全性表演。通过这件事，我认为解决方案的主要目的是避免指控 — 而不是真正保护客户。
我想看看附件到底是什么。结果发现它是一个 ActiveX® 控件对象。为了查看这个附件，我不得不在 Internet Explorer® 中打开它并安装此对象。它显示了如图 5 所示的安全屏幕。正如您所看到的，设计人员竭力使邮件看起来像一个普通的邮政信封；它甚至还包含一张邮票，声称信封是受信任的。
图 5 安全文档显示了一个标记为“受信任”的信封（单击图像可查看大图）
此类技术令人担忧的原因有多种。首先，它会使用户方养成一个非常不好的习惯：打开未经请求的附件。其次，在实际的邮件中，它给出了一种非常不负责任的做法，就是将系统配置为不经提示直接打开附件。第三，面对计算机提示的矛盾信息（即电子邮件说它是受信任的，而 Outlook 说不是），邮件看起来非常可疑。最后，实际的附件包含了一个毫无意义的安全假象，让用户确信它是受信任的。如果用户信任此类邮件，很可能也会轻易信任具有类似外观的其他恶意邮件。
提供安全通信
不可否认，此技术打算解决的问题非常重要。以一种受信任的方式与客户通信非常困难。然而，这个特殊的解决方案有点超工程设计了。它很可能会使客户产生困惑并可能最终导致与原来的目标相反的结果：客户系统遭到破坏。
经过精心设计的网站现在使用的是“邮件中心”。在这种设计中，当公司需要与客户通信时，它会发送一封包含类似以下内容的电子邮件：“您在邮件中心有一封邮件。请转到我们的网站，登录并单击‘邮件中心’链接以查看该邮件。”如果公司使用安全多用途 Internet 邮件扩展 (S/MIME) 协议对客户收到的所有电子邮件都进行签名以使用户能够验证其来源，则此公司值得表扬。如果电子邮件中不包括“请单击此链接”之类的内容，也值得表扬。用户应手动键入公司的 URL 以确保转到预期的站点。
通过采用邮件中心和邮件签名等措施，公司可建立一个与客户进行通信的受信任途径。客户在邮件工作流期间看到的所有内容都是经过验证的，而且公司不会采用不良的安全实践。
关于隐私
到目前为止，我已经通过本系列文章中的前两部分介绍了安全专业人员是如何在客观上对用户造成伤害的。维护安全是我们的职责。但制定的许多决策以及实施的许多解决方案都让用户感到困惑，会使他们做出错误的决策并给他们带来一种安全错觉。我们不应让这些矛盾的想法使用户变得无所适从。
正如我之前指出的，对于大多数用户而言，安全性只是保护密码和信用卡号码。他们需要的是有效而且可信赖的技术。不幸的是，他们必须做出抉择，而我们的职责就是确保他们清楚自己的行为。
在本系列文章的最后一部分中，我将介绍消费者可以使用的一些最重要技术为何没有实现预期的目的。我还会提出我的倡议。因此，敬请期待 2008 年 9 月的“安全观察”专栏。
Jesper M. Johansson 是研究安全软件的软件架构师，还是《TechNet 杂志》的特约编辑。他拥有管理信息系统博士学位，具有 20 多年安全方面的经验，并且是企业安全领域的 Microsoft 最有价值专家 (MVP)。他的最新著作是《Windows Server 2008 安全资源工具包》。
© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利；未经允许不得复制本文的部分或全部内容。