Day20-不能说的秘密（二）

前言

昨天有说到在储存使用者的密码时，不管是用 AES 把他们加密起来，或是经过 SHA1 杂凑之後再进资料库，都已经不够安全，所以今天这边还要提出另外一种更好的方式，让你更妥善的把使用者的密码保管好

现今 CPU 的极限

就如昨天说的，单纯的杂凑之所以不够安全，是因为 CPU 计算杂凑的速度太快了，因此只要有人建表把 00000000 到 zzzzzzzz 的 SHA1 杂凑值全部都算出来，就可以发现 1785bf0ed0f6346210af2d64b310a99b4024ce44 是由 love1234 经过 SHA1 出来的结果，进而得到原本的密码

虽然现在的 CPU 真的跑很快，但也是有他的极限的，刚刚的 love1234 之所以可以被破解其实是因为他太简单了，只要把长度为 8 的字串杂凑值都算过一遍就好。而且小写字母加上数字也才 36 个字元，算一算 36⁸ 大约才 2.8 兆种组合，不用花太多时间就可以建一个表出来

但如果你的密码又臭又长又乱、包含了大小写甚至还有一些怪怪的字元，像是 -y]@7k[BSB@3m]r$.>"R，那以现在电脑的计算速度就还无法破解，因为长度 20 以内由数字、大小写还有特殊字元组成的字串太多了，算到天荒地老都不见得能算出来。

但身为网站的开发者，不太可能要求所有使用者都设这种密码，毕竟这种密码太难记，每天光忘记密码就饱了。所以大部分的使用者密码还是会像 love1234，甚至还有更简单的 123456 或是 qwerty 这类的XD，有兴趣可以看看维基百科上 最常被使用的 25 个密码

加盐杂凑

为了解决使用者密码太简单的问题，於是有了所谓的加盐，他的的基本概念就是使用随机字串帮使用者的密码加长**

如果今天有一个新的使用者要注册，这时我们的後端系统就随机生成一个长度十的字串称作 Salt，计算 Hash 时就把使用者输入的密码跟 Salt 合在一起算。以下图为例，若使用者 SmallTown 注册时後端随机生成的盐是 h7.@-]%<#L，而他输入的密码是 helloworld，那就计算 SHA1("helloworld" + "h7.@-]%<#L") 得到 f80533d9f6a59796080258d2d4a2e2ec548322d4，然後把 salt 跟 hash 结果都存起来

因为 salt 会存在资料库里面，所以当有天小城要登入时，就把他输入的密码加上资料库内的 salt 杂凑，看会不会得到相同的杂凑值，如果相同的话代表小城输入的密码是对的

安全性方面，因为那一大串 f80533d... 是 helloworldh7.@-]%<#L 经过 hash 後的结果，而 helloworldh7.@-]%<#L 本身也够长够乱，网路上的表根本不可能包含这个字串，所以把 f80533d... 那一大串丢到网站上也破解不出来，换句话说无法得知小城的密码是 helloworld

但如果骇客真的拿到你家资料库，代表他同时拿到每个人的 salt 和 hash value，虽然骇客无法像先前那样直接查网路上的表，但他还是可以用自己的电脑算杂凑值，从 aaaaaaaaaa 到 zzzzzzzzzz 把每个字串都加上 h7.@-]%<#L 再做 hash 还是可以算出小城的密码是 helloworld

虽然真的要算的话也是可以，但因为每个人的 salt 都不同，所以要把所有使用者的密码都算出来的话可能需要租一台超级电脑来算。如果骇客得到使用者的密码後无法获得相对应的利益，那其实就是白花钱而已，所以很多骇客看到资料库内的密码有加盐就会放弃了

换句话说，身为网站开发者，在储存密码时至少要加盐再杂凑，而且随机产生的 salt 尽量要含有特殊字元，这样才能保证使用者的密码安全

小结

今天介绍了所谓的「加盐杂凑」，虽然说现在的网站应该都要做到这种程度才能保障使用者密码的安全，但其实有很多网站还是停留在普通的 SHA1 杂凑，甚至少数还有直接存明码的 ?，所以平常在注册时个网站还是尽量用不同的密码，才不会被这些网站拖下水

虽然加盐杂凑对现在的 CPU 计算速度来说已经足够安全，但以後的 CPU 只会越来越快，因此明天还要介绍一种更好的方式，让你的网站即便有一天 CPU 比现在又快一千倍，也不会担心使用者的密码被反解回来～