如何安全地存储密码

菜鸟方案：

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

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

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

　　入门方案：

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

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

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

　　单向哈希有两个特性： 1）从同一个密码进行单向哈希，得到的总是唯一确定的摘要 2）计算速度快。随着技术进步，尤其是显卡在高性能计算中的普及，一秒钟能够完成数十亿次单向哈希计算

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

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

　　进阶方案：

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

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

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

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

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