密码存储发展过程

最简单常用的认证方式就是用户名、密码登录了，密码保存到数据库时，常见的加密方式有哪些，我们该采用什么方式来保护用户的密码呢？以下为我的认知过程，记录分享下

明文存储

比如用户设置的密码是“123456”，直接将“123456”保存在数据库中，用户登录的时候对比密码就可以。

起初这些密码被认为是安全的，因为存储在数据库中，而数据库是安全的，需要凭证来访问。然而，恶意用户能够通过使用 SQL 注入等攻击手段，找到获取大量用户名和密码的 “data dumps” 的方法。也就是敏感信息被转移到非敏感信息，然后可以通过一般的查询手段获取用户名、密码。

由于各种数据库漏洞层出不穷，实际上很难避免密码被访问，那么就有了其他的密码存储方式。

单向哈希运算

开发者们被鼓励在对密码进行单向哈希运算后进行存储，例如 SHA-256。

比如123456经过 SHA-256 运算后是8D969EEF6ECAD3C29A3A629280E686CF0C3F5D5A86AFF3CA12020C923ADC6C92，将后面这一长串存储在数据库中，当用户试图验证时，哈希密码将与他们输入的密码的哈希值进行比较。

如果发生漏洞，只有密码的单向散列值被暴露。由于哈希值是单向的，而且根据哈希值猜测密码在计算上是很困难的，所以不值得花费精力去弄清系统中的每个密码。为了破解密码，黑客决定创建被称为[彩虹表]的查询表。

彩虹表攻击将使用包含哈希及其纯文本等价物的预生成文件来破解存储在数据库中的密码。

比如我有一个准备好的表格，里面记录了一些常用密码的哈希值，比如123456对应的8D969EEF6ECAD3C29A3A629280E686CF0C3F5D5A86AFF3CA12020C923ADC6C92，那么如果在密码库中查询到了8D969EEF6ECAD3C29A3A629280E686CF0C3F5D5A86AFF3CA12020C923ADC6C92就表示这个密码是123456，密码已被破解。

接下来开发者有了信的思路，加盐（salt）。

SALT

为了解决彩虹表问题，开发者开始使用加盐的密码做哈希处理。

比如在进行哈希运算的时候，给密码加点盐。使用salt123456 经过 SHA-256 运算后是9898410D7F5045BC673DB80C1A49B74F088FD7440037D8CE25C7D272A505BCE5。这样的话上文中的彩虹表就失去了效果，在不知道盐具体是什么的情况下，根本没办法进行对比。

这种方式也有弊端，就是这个盐不能换，换了之后验证无法通过。那么这种方式被破解的可能就是盐被泄露，然后就可以通过彩虹表的方式破解了，这也真正的发生过，经过漫长的产品迭代周期，接触盐的人越来越多，难免不被泄露。

这时候，开发者想到可以通过添加随机盐的方式避免盐被泄露。

随机 SALT

上面提到，我们害怕盐被泄露掉，那么就不保护盐了，明文保存盐。

在存储密码值的时候，首先生成一个随机的盐randomsalt,然后和真正的密码123456一起组合成randomsalt123456.经过 SHA-256 运算后是9EC80769CC272B7D748B9DF1E13CCE62F8A0C08C804722300048FD5B29655CE8，存到数据库中的值是randomsalt.9EC80769CC272B7D748B9DF1E13CCE62F8A0C08C804722300048FD5B29655CE8

上文只是举了例子，实际上随机盐的生成是很讲究的，不能太短，不能重复等。由于每个密码的盐都不一样，直接避免了彩虹表破解的可能。

但是由于计算机硬件飞速发展，使得暴力破解密码成为可能。可以在一秒钟内进行数十亿次的哈希计算，黑客不再依赖彩虹表，而是使用定制过的硬件和专用算法，直接计算每一种可能。这意味着，我们可以轻松地逐一破解每个密码。

Password Hash

由于硬件加速发展，导致哈希运算过快，那么就整个慢点的哈希运算。针对这一点，密码学家们设计了 PBKDF2、BCRYPT、SCRYPT 等用来加密密码的 Hash 算法，称作 Password Hash。在他们的算法内部，通常都需要计算 Cryptographic Hash 很多次，从而减慢 Hash 的计算速度，增大黑客暴力破解的成本。Password Hash 有一条设计原则，就是计算过程能够按要求变慢，并且不容易被硬件加速。

由于这种运算还可以设置运算强度，一般建议在你的系统上验证一个密码需要大约一秒钟。这种权衡是为了使攻击者难以破解密码，但又不至于使你自己的系统负担过重或刺激到用户。因为不能进行硬件加速，这样的话暴力破解就很难了，也是目前比较推荐的密码存储方式。