唉，我多么怀念从前攻击者们能够轻易获取密码散列的时光。那个时候，防御此类攻击方式只需三个步骤：第一、保护好自己的密码散列不被窃取;第二、使用强度较高的密码散列;第三、保证使用较长的密码以免遭到破解。

　　如今，从密码散列入手已经是过时的招数。当下攻击者们采用的是清一色的hash注入攻击。通过这种攻击方式，那帮混球能够取得散列--无论是从密码散列存储数据库中还是内存中--并利用它们重新生成一套完整的身份验证会话。

　　密码散列--或任何一种身份验证模式--是登录行为成功与否的核心所在。这类信息是通往禁宫的钥匙，因此几乎每种安全保障机制都在尽力试图防止攻击者拿到身份验证资料。倘若他或她获得了超级管理员访问权限，那么任何操作、任何实施途径对他们来说都是可行的，而且整个过程绝对会畅通无阻--因为对于防御体系来说，他们是完全合法的。

　　hash式攻击能够成功攻克任何操作系统及任何身份验证协议，甚至Kerberos协议(由麻省理工学院开发的一套强力安全认证系统)对此也束手无策。此项技术同样适用于智能卡类的登录行为(因为在微软的Windows系统中，网络终端上的密码散列的存储及调用仍然源自局域网管理器上的验证机制)。

　　我一直试图向客户们灌输这样的思路，即真正可怕的并不是hash攻击本身。我们需要关注、且有能力关注的应该是如何将那些混球制止在实施hash攻击前所必需的准备工作过程中。在攻击者已经获得了超级管理员身份时还执着于如何对抗hash攻击，就像是在自己的车被小偷盗走后，还在心存侥幸地观望车上的手刹是否能放缓他的脚步一样。不过，当hash攻击反复来袭时，它必然会引起我们--及我们的客户--的注意。事实上，此类攻击时下确实有愈演愈烈之势。

　　抵御注入

　　正如我在前面提到的，能够完全抵御hash攻击的终极机制并不存在，但这并不意味着我们就应该在此类侵袭面前坐以待毙。安全性毕竟并不是二进制代码，也不是非黑即白的二选一。安全性的真正含义是在完全安全与完全危险之间取较为适中的某个平衡点。

　　我曾经看到过通过禁用低强度密码散列来对抗高级持续威胁的技术，这种办法即使在攻击者的工具非常强大、能够轻松应对高强度密码的情况下仍然能够奏效。因为攻击者事实上根本不知道较弱的密码散列已经被禁用，因此他们认为没必要尝试hash攻击。

　　在林林总总的hash攻击防御方案之中，防止攻击者获取超级管理员访问权限无疑是最重要、最核心的手段。遗憾的是，在多年来的传统计算机安全防御工作讨论中，我已经无数次强调过保持登录用户权限最小化、反恶意软件工具、白名单、防火墙等等的必要性。然而，我的客户们往往不会主动就hash攻击跑来求助，直到他们意识到自己的防御体系已经形同虚设。

　　我们可以设下层层阻碍，令攻击者无法顺利将散列信息从内存中提取出来。在Windows系统中，密码散列能够通过下列登录类型从内存中提取得到：交互、批处理、服务、解锁、远程交互以及缓存交互。表面上看这似乎已然包括了我们耳熟能详的所有登录类型，但是请注意，网络登录并不在其中。因此，单纯对共享中的NetBIOS驱动器进行访问是无法从内存中提取出密码散列的。

　　另外，尽管注销操作常常能帮我们清空内存中的密码散列，但应用程序及API却可能对其予以完整保留，因此这种作法并不完全可靠。注销后再重新启动计算机的方式最为理想，它能保证内存中不再残留任何涉及密码散列的信息。

　　阻断上述途径

　　我常常提醒客户，务必尽量减少前文提到过的各类特权账户登录类型。在大多数运行环境中，我一般会利用远程桌面协议或其它类型的交互式远程软件来进行管理、故障排除并访问服务器及工作站。这种方式简单高效，但副作用也同样明显--高权限信息往往会残留在运行环境当中，而此种状况如果发生在存在木马或是不受信任的机器上，后果无疑非常严重。

　　相反，我鼓励客户通过非交互式的方法来管理计算机。使用控制台工具代替远程桌面协议，我们同样能够以远程方式连接到目标计算机。大多数微软管理控制台工具能够重新定向到新的远程目标计算机。还有，用PowerShell脚本代替手动输入密码的过程。

　　我有许多优秀的同事，他们与我抱有同样的观点，即尽可能取消所有具备超级管理员权限的账号--或者最多保留一个。在微软Active Directory体系中(我本人正是一位全职微软员工)，我们可以利用"授权"功能为指定用户提供管理员权限，但又不像超级管理员那样能够掌控一切，这种方案类似于设置域管理员或是企业业务管理员。就我所知，没有哪位域管理员或业务管理员在完全工作时真正需要超级管理员那么高级别的执行能力。相反，只赋予工作人员必需的权限既不会影响他们的正常操作，在散列被窃取后，攻击者也无法获得超级管理员账户。

　　我的客户群体中有一些将希望寄托于频繁频繁再频繁地修改密码或者使用一次性密码。的确，如果攻击者获得的是此类散列，他们能够实施操作的时间会变得相对比较短。有多种供应商工具能够协助我们达成上述目标。同时，最大限度避免密码重复使用也能在保障密码散列丢失时防止其它安全区块发生危险。

　　最好尝试使用最新的操作系统。它们总是具备一些早期版本所没有的防御体系。举例来说，在Vista、Windows 7以及Windows Server 2008(及之后的版本)中，传统的NT散列被基于Kerberos协议的AES散列所取代。虽然hash攻击的发起者可能最终还是能够侵入AES，但至少目前来说他们对此还没有太好的办法，因为眼下还没有哪款hash攻击工具是针对AES制作的。尽管这种安全状态只是暂时的，不过还是要牢记安全的概念是模糊的。任何能够有效降低hash攻击危险的方案都是很有价值的。

　　"弹"窗很重要

　　另一项重要建议是：管理员们应该在执行管理任务时抱有最大的安全性考量，且只使用受信任的计算机。大家不应该推诿管理职责，而是将其贯彻到日常的网页浏览、电子邮件接收以及访问社交网站的全部流程当中。此外，在处理管理方面的任务时尽可能创建"弹"窗。这些弹窗较难(希望如此)受到影响，也就从另一个侧面保护了超级管理员的散列信息。当弹窗处于最前时，管理员应该使用非交互式远程工具来实现对其它对话框体的管理。这样一来，散列内容实际上存储在另一台计算机的内存当中。如果管理员以交互式方式登录到其它某台不受信任的计算机上时，请确保先注销、再重启这一安全操作流程。

　　有些企业甚至将"弹出"域设置为管理员专用。他们采取单向的、有选择性的信任方式，借以避免某类身份验证信息会钻了可信任及不可信任两种标准之间的空子。

　　还可以考虑利用IPsec或者AuthIP对特定计算机之间的互相登录进行限制，以防止攻击者在所有计算机上使用窃取来的散列信息。最后，请一定记住保持可以检测出hash攻击工具的反恶意软件始终处于运行状态。一旦发现潜伏于我们网络周围蠢蠢欲动的危险因素，忙碌的一天也将随之开始。

　　我希望自己在这篇文章中分享的一些新方法能够切实帮助大家减少hash攻击带来的种种风险。如果各位在这方面有独到的见解或技巧，也请不吝指教。