验证用户密码这件事

30 Apr 2015

本篇经与 @Gnnng, @pollow 讨论、查资料，在 MSTC 群中请教讨论总结而成。

我们都知道，数据库里不能储存用户密码的明文，那怎样存储才是最科学的呢？

为什么不能存明文？

仔细想想，即使使用明文放在数据库里，用户还是看不到别人的密码，那为什么不能使用明文存储呢？这是因为你不能保证自己数据库的安全。之前 CSDN 因为一个漏洞整站数据库被拖下来，用户的帐户名和密码就全部暴露在网站上了。这带来一个更严重的问题，很多人在不同的站点上使用的都是同一个用户名和密码，别人拿着这个被暴露出来的密码到其他各大网站，比如淘宝，支付宝，网银等等试一下，用户的损失就严重了。

加密 Hash

加密 Hash 是对数据的单向映射。单向映射就是指拿到 hash 后的值，无法得到原来的数据。上面那个问题，如果我们把用户的密码 hash 一下再放到数据库里，然后每次用户登入的时候我们拿到用户的真实密码都先 hash ，再与数据库中的值进行比对，这样即使数据库被人拖下来，他也无法通过那个 hash 后的值得到用户的真实密码了。

Rainbow Table

可是真的是这样吗？一定程度上说是的，别人得到 hash 之后，的确几乎不可能逆向算出原始密码。但换个思路想一想，用户的密码通常是简单并且容易构造的，只要把这些常见的密码 hash 一下得到这个对应关系表，就很容易得到原始密码了。这样的对应关系表通常被称为彩虹表¹（Rainbow Table)。

现在黑客们已经构造出 TB 级别的彩虹表²，所以很多直接 hash 得来的密码都会被直接查询到。

Salt

那用什么办法可以防止彩虹表的直接查询呢，有人提出了一个解决方案——加盐（salt)。具体来说就是得到用户的真实密码后，再随机生成一个字符串（即盐），把密码和盐用某种方式组合起来（即加盐）然后再 hash 后放后数据库中，同时把盐也放入数据库中。用户登入的时候，从数据库中取出对应的盐，再和得到的用户密码组合一下进行 hash ，与数据库中的 hash 值比对即可。

那为什么这样就能避免彩虹表碰撞呢？如果数据库被人拖下来，他获得了 hash ，同时也获得了盐，如果碰撞成功，他应该很容易通过拿到的盐得出用户真实密码啊？

是，也不是。

其实加盐的真实目的，是对用户的密码进行强化。用户常常会使用弱的密码，比如几位纯数字之类，这太好构造，很容易碰撞出来。但是如果是几十位，甚至几百位的大小写字母加数字还有特殊字符，这就很难构造了，因为这样的组合数目实在太多了。我们可以看到在 Rainbow Crack 这个网站上面，1 - 9 位数字和字母的组合就达到了 13,759,005,997,841,642 种之多，数据量达到了 864 GB，在这个基础上每增加一位或者增加一种字符带来的都是指数级别的数据量增长。因此，只要我们的盐足够强，很难用彩虹表碰撞成功。而换一种策略，即使他使用拿到的每个盐去构造新的一些彩虹表，代价也是巨大的。

多 hash 几次？

有些人可能会想到，拿到用户的密码后，多 hash 几次会不会从一定程度上避免彩虹表碰撞呢？答案是否定的。事实上，和大多数人想象得正好相反，这样做反而更加不安全。

前面说，hash 函数是不可逆的，这是因为在 hash 的过程中丢掉了原始数据的部分信息。也就是说，hash 是减熵的。当进行多重 hash 的时候，整体的安全性其实取决于最弱的那个 hash 函数，因为如果单一 hash 碰撞，多重 hash 一定碰撞。

把上面那句话用表达式写出来：

比如原先有函数 \(hash_1\)，并且

\[y_1 = hash_1(x_1) = hash_1(x_2)\]

数据库里面存储了 \(y_1\) 作为校验，原始密码是 \(x_1\)。如果有人碰撞出了 \(x_2\) ，在我们的数据库中就验证成功了。

而现在又有函数 \(hash_2\)，并且

\[z = hash_2(y)\]

并且有

\[z_1 = hash_2(y_1) = hash_2(y_2)\]

同时又有

\[y_1 = hash_1(x_{11}) = hash_1(x_{12}) \\ y_2 = hash_2(x_{21}) = hash_2(x_{22})\]

如果用户使用 \(x_{11}\) 作为密码，那么使用 \(x_{12}, x_{21}, x_{22}\) 都可以得到相同的 \(z_1\)，所以更加不安全了。

换种思路窃取密码

如果我们按照上面的策略存储密码了，可以暂时认为数据库方面是安全的了。如果要想窃取用户的密码，就应该从更薄弱的环节入手，比如网络传输。现在仍然有大量的网站没有使用 HTTPS 传输数据，这意味着用户发送的数据可能在经过的每一个路由节点上被监听到。所以还没等服务器拿到用户的密码原文，中间人已经获取到所有想要的信息了。

这时候怎么办呢？最好的解决办法就是换成 HTTPS，从根本上避免这种监听。但如果做不到，我们可以退而求其次想一些折衷的办法³。

策略一，前端直接 hash 密码送到后端进行加盐 hash。不可行。因为如果有人从别处已经得到了一些 hash 后的值，那么他就不需要猜测用户原来的密码，直接把 hash 送到后端进行验证就行了，反而降低了难度。

策略二，在前端加盐 hash ，再传到后端直接进行比对。不可行。这给黑客提供了一个方便——他不需要知道密码就可以方便地在你这里验证某些用户名或邮箱是否是有效的。

策略三，既然不能从后端获取 salt ，那简便的方法就是使用前后端约定好的一个固定的 salt 进行 hash，比如用户的用户名，或者邮箱。这样就保证了中间人监听不到真实的密码，同时又因为在后端又进行了一次安全的加盐 hash ，保证了数据库的安全性。

用什么 hash 函数？

1. 经过安全测试的加密 hash 函数，如： SHA256, SHA512, RipeMD, WHIRLPOOL, SHA3 等等
2. Key Stretching 算法，如： PBKDF2, bcrypt, scrypt 等
3. 安全版本的 Unix crypt，如： $2y$, $5$, $6$

总结

• 前端使用固定 salt 加密后送给后端
• 后端生成强大的 salt 将前端送来的值加密储存
• 使用安全的 hash 函数
• 如果可能，使用 HTTPS

参考资料