过去一段时间来，众多的网站遭遇用户密码数据库泄露事件，这甚至包括顶级的互联网企业–NASDQ上市的商务社交网络Linkedin，国内诸如CSDN一类的就更多了。

    层出不穷的类似事件对用户会造成巨大的影响，因为人们往往习惯在不同网站使用相同的密码，一家“暴库”，全部遭殃。

    那么在选择密码存储方案时，容易掉入哪些陷阱，以及如何避免这些陷阱？我们将在实践中的一些心得体会记录于此，与大家分享。

    菜鸟方案：

    直接存储用户密码的明文或者将密码加密存储。

    曾经有一次我在某知名网站重置密码，结果邮件中居然直接包含以前设置过的密码。我和客服咨询为什么直接将密码发送给用户，客服答曰：“减少用户步骤，用户体验更好”；再问“管理员是否可以直接获知我的密码”，客服振振有词：“我们用XXX算法加密过的，不会有问题的”。殊不知，密码加密后一定能被解密获得原始密码，因此，该网站一旦数据库泄露，所有用户的密码本身就大白于天下。

    以后看到这类网站，大家最好都绕道而走，因为一家“暴库”，全部遭殃。

    入门方案：

    将明文密码做单向哈希后存储。

    单向哈希算法有一个特性，无法通过哈希后的摘要（digest）恢复原始数据，这也是“单向”二字的来源，这一点和所有的加密算法都不同。常用的单向哈希算法包括SHA-256，SHA-1，MD5等。例如，对密码“passwordhunter”进行SHA-256哈希后的摘要（digest）如下：

    “bbed833d2c7805c4bf039b140bec7e7452125a04efa9e0b296395a9b95c2d44c”

    可能是“单向”二字有误导性，也可能是上面那串数字唬人，不少人误以为这种方式很可靠，其实不然。

    单向哈希有两个特性：

    1）从同一个密码进行单向哈希，得到的总是唯一确定的摘要

    2）计算速度快。随着技术进步，尤其是显卡在高性能计算中的普及，一秒钟能够完成数十亿次单向哈希计算

    结合上面两个特点，考虑到多数人所使用的密码为常见的组合，攻击者可以将所有密码的常见组合进行单向哈希，得到一个摘要组合，然后与数据库中的摘要进行比对即可获得对应的密码。这个摘要组合也被称为rainbowtable。

    更糟糕的是，一个攻击者只要建立上述的rainbowtable，可以匹配所有的密码数据库。仍然等同于一家“暴库”，全部遭殃。以后要是有某家厂商宣布“我们的密码都是哈希后存储的，绝对安全”，大家对这个行为要特别警惕并表示不屑。有兴趣的朋友可以搜索下，看看哪家厂商躺着中枪了。

 [page]   进阶方案：

    将明文密码混入“随机因素“，然后进行单向哈希后存储，也就是所谓的”SaltedHash”。

    这个方式相比上面的方案，最大的好处是针对每一个数据库中的密码，都需要建立一个完整的rainbowtable进行匹配。因为两个同样使用“passwordhunter”作为密码的账户，在数据库中存储的摘要完全不同。

    10多年以前，因为计算和内存大小的限制，这个方案还是足够安全的，因为攻击者没有足够的资源建立这么多的rainbowtable。但是，在今日，因为显卡的恐怖的并行计算能力，这种攻击已经完全可行。

    专家方案：

    故意增加密码计算所需耗费的资源和时间，使得任何人都不可获得足够的资源建立所需的rainbowtable。

    这类方案有一个特点，算法中都有个因子，用于指明计算密码摘要所需要的资源和时间，也就是计算强度。计算强度越大，攻击者建立rainbowtable越困难，以至于不可继续。

    这类方案的常用算法有三种：

    1）PBKDF2（Password-BasedKeyDerivationFunction）

    PBKDF2简单而言就是将saltedhash进行多次重复计算，这个次数是可选择的。如果计算一次所需要的时间是1微秒，那么计算1百万次就需要1秒钟。假如攻击一个密码所需的rainbowtable有1千万条，建立所对应的rainbowtable所需要的时间就是115天。这个代价足以让大部分的攻击者忘而生畏。

    美国政府机构已经将这个方法标准化，并且用于一些政府和军方的系统。这个方案最大的优点是标准化，实现容易同时采用了久经考验的SHA算法。

    2）bcrypt

    bcrypt是专门为密码存储而设计的算法，基于Blowfish加密算法变形而来，由NielsProvos和DavidMazières发表于1999年的USENIX。

    bcrypt最大的好处是有一个参数（workfactor），可用于调整计算强度，而且workfactor是包括在输出的摘要中的。随着攻击者计算能力的提高，使用者可以逐步增大workfactor，而且不会影响已有用户的登陆。

    bcrypt经过了很多安全专家的仔细分析，使用在以安全着称的OpenBSD中，一般认为它比PBKDF2更能承受随着计算能力加强而带来的风险。bcrypt也有广泛的函数库支持，因此我们建议使用这种方式存储密码。

    3）scrypt

    scrypt是由着名的FreeBSD黑客ColinPercival为他的备份服务Tarsnap开发的。

    和上述两种方案不同，scrypt不仅计算所需时间长，而且占用的内存也多，使得并行计算多个摘要异常困难，因此利用rainbowtable进行暴力攻击更加困难。scrypt没有在生产环境中大规模应用，并且缺乏仔细的审察和广泛的函数库支持。但是，scrypt在算法层面只要没有破绽，它的安全性应该高于PBKDF2和bcrypt。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。