安全崩盘年代：拖库攻击谈口令字段加密策略

　　单独使用对称算法

　　在标准HASH安全破灭后，又看到有人呼吁用AES，其实这不是一个好建议。AES这些对称算法，都不具备单向性。网站被攻击的情况是复杂的，有的是只有数据库被拖，有的则整个环境沦陷。而后者AES密钥一旦被拿到，密码就会被还原出来，这比被查表还要坏。

　　当然我们还看到一种把AES当HASH用的思想，就是只保留一部分的AES加密结果，只验证不还原。但其实这样的AES并不见得比HASH有优势。比如即使攻击者没有拿到密钥，也只拖了库，但攻击者自己在拖库之前注册了足够多的帐号，并使用大量不同的短口令。那么就拿到了一组短明文和对应密文。而此时密钥是完全有可能被分析出来的。

　　而使用DES、AES一类的算法，还是使用标注HASH，还是自己设计算法，如果不解决不同用户相同口令密文相同的统计性缺陷，那么攻击者即使拿不到密钥，也都可以先把一些高频口令用于帐号注册，拖库后进行密文比对。就可以锁定大量的采用常见口令的用户。

　　加“一粒盐”

　　其实很多同仁都指出了哈希加盐法(HASH+SALT)，是问题的解决之道，所谓加盐(SALT)其实很简单，就是在生成HASH时给予一个扰动，使HASH值与标准的HASH结果不同，这样就可以抗彩虹查表了。

　　比如说，用户的密码是123456，加一个盐，也就是随机字符串“1cd73466fdc24040b5”，两者合到一起，计算MD5，得到的结果是6c9055e7cc9b1bd9b48475aaab59358e。通过这种操作，即便用户用的弱密码，也通过加盐，使实际计算哈希值的是一个长字符串，一定程度上防御了穷举攻击和彩虹表攻击。

　　但从我们审计过的实现来看，很多人只加了“一粒盐”。也就是说，对同一个站点，不同用户使用同一个密码，其密文还是相同的。这就又回到了会遭遇高频统计攻击，预先注册攻击等问题。

　　口令的安全策略

　　在传统密码学家眼中只有一种加密是理想的，那就是“一次一密”，当然事实上这是不可能的。但如果我们套用这种词法，我们也可以说，口令安全策略的理想境界，我们可以称为单向、一人一密、一站一密。

　　单向：标准HASH算法的价值尽管在这个场景下，已经被推倒，但其单向性的思想依然是正确的，口令只要是能还原的，就意味着攻击者也能做到这一点，从而失去了意义，因此使用单向算法是必须的。

　　一人一密：同一个站点设置同样口令的不同用户，加密生成的密文内容并不相同。这样就能有效的应对结果碰撞和统计攻击。采用字典的攻击的方法基本是不收敛的。

　　一站一密：仅仅保证一人一密是不够的，还要保证使用同样信息、同样口令去注册不同网站的用户，在不同站点的口令加密结果是不同的。鉴于有大量用户用同样的信息、同样的口令去注册不同网站，如果能做到这一点，流失出的库信息会进一步打折扣。而攻击者基本会放弃生成密文字典的尝试。

　　实现这些说起来很简单，依然是HASH+SALT，关键在于每个站点要有不同的SALT，每个用户要有不同的盐。

　　但如果攻击者不是只获得了库，而且也获得了相关的加密参数和密钥，我们就要看到攻击者依然可以自己通过相关参数和密钥调用算法，使用常见密码对每个用户生成一遍密文，然后是否有匹配。当然我们可以看到由于“每人一粒盐”的策略，攻击者所需要的计算代价已经变化了，如果过去只需要生成一次的话，那么假如使用100个常见的口令来做，那么只要口令没有碰撞到，对每个用户都要做100次加密操作。但这也是不容小觑的威胁。因为有太多用户喜欢使用那些常见口令。

　　因此，设定一个密码禁用表，让用户避免使用常见口令，可以进一步让破解者付出更大的代价，从而最终导致计算资源不收敛而放弃，也可以是一个可以考虑的策略。但也需要提醒WEB开发者的是，这样会增大你的用户忘记口令的风险。

　　另外，用户是否有把密码设置为123456的自由呢，我想只要不是国防、航天、涉密系统和有安全要求的企业环境，如果只是潜潜水、骂骂街，网站或许提醒用户就好，但也许并不需要做成强制策略。

　　具体的实现

　　了这么多，怎么来具体实现一站一密、一人一密的策略呢，2011年12月23号，我们想到与其空洞的说教算法原理和策略，不如提供一些非常直接的示例程序和文档。

　　因此同事们写了一份名为AntiyPasswordMixer(安天密码混合器)的开源代码，当然这没有什么技术含量，也不是“自有知识产权的国产算法”，有的只是对实现较好的流行开源算法包的示范性使用而已，目前的Python版本，也只有三百行代码，在其中封装了RSA和HASH+SALT使用，并给出了具体的在初始化、注册和认证时如何使用的范例文档。

　　大家可以在这里找到这个东西：http://code.google.com/p/password-mixer/

　　当然，就像我们惋惜很多应用开发者缺乏对安全的重视一样，其实我们并不懂应用开发，所以这些代码和文档对于应用开发者看来可能非常丑陋。尽管可能被鄙视，我们还是要打开门，证明安全团队并不保守。

　　而同时，我们必须与应用走得更近，因为我们也在使用着这些自认为违反了某种安全原则的应用，却因为不是其开发者而无法改造它们。

　　过去的10余年，中国的Web应用甩开安全而飞速狂奔，开发者们凭借自身的勤奋和冲击力奠定了现有的格局，但也因快速地奔跑遗落了一些东西，比如安全。也许现在是拾起这些弃物的时间了。

　　中国的安全界则因保守、敏感和很多自身的原因，与应用的距离越拉越远，在我们还在幻想某些完美的安全图景时，发现我们已经望不到应用的脊背了。也许，在应用会回头等等我们的时候，就是我们加速前行、拾起应用所遗落的安全性，追送上去的时间了。

　　本文作者肖新光，网络ID江海客，安天实验室首席技术架构师，研究方向为反病毒和计算机犯罪取证等。如果有读者想要就安全问题和作者探讨，可以在微博@江海客。