很久以前看到一篇文章，讲某个大网站储存用户口令时，会经过十分复杂的处理。怎么个复杂不记得了，大概就是将口令先 Hash，结果加上一些特殊字符再 Hash，然后中间插入些字符再 Hash、再怎么怎么的。。。看的眼花缭乱。
当时心想这么复杂应该很安全了吧。事实上即使现在，仍有不少人是这么认为的。所以在储存账号口令时，经常会弄些千奇百怪的组合。
不过，千奇百怪的 Hash 算法究竟有意义吗？在什么情况下能派上用场？是否有更简单合理的替代方案？这问题先从拖库说起。
知道算法才能破解
数据库中的口令，都是以 Hash 形式储存的。拖下数据库后，如果要猜某个账号的明文口令，得通过跑字典的方式：
for each word in 常用词汇
if H(word) == E
print "明文："，word
exit
不过，光有泄露的数据 E 不够，还得知道算法 H 才能跑的起来。光有 Hash 值，却不知道用的是那种 Hash 算法，仍然无从下手。
当然很多小网站，数据库和算法在同个系统里，一旦入侵两者都泄露了；但若数据库和算法不在同个系统里，即使能拖库也未必知道算法。
猜算法
不过即使搞不到算法，也可以尝试猜测。比如先在网站上注册个账号 —— 例如口令为 123456，然后在泄露的库中，根据用户名找到对应口令的 Hash 值，例如 dd6e5e5918e94d997c686fcebc56922f。
这时，就可以暴力猜算法了：
for each fn in 常用算法
if fn("123456") == dd6e5e5918e94d997c686fcebc56922f
print "算法：", fn
exit
不难猜出，fn 为 f(x) = md5(sha256(x))。知道了算法，就可愉快的跑字典了。
奇怪算法
这时「奇怪算法」的优势就体现出来了。 如果使用的算法十分奇葩，比如：
f(x) = md5("hello~" + sha1(sha256(x)) + "world!")
根本不在常用算法里，几乎难以穷举到，于是就能躲过「猜算法」这种攻击方式。
所以，奇怪的算法是有意义的！
不过奇怪、奇葩、变态...这些都是人的主观感觉，并不能用理性来衡量。比如说刚才那个算法有多复杂？你只能说很复杂，而难以给出一个准确的程度。
算法简单，数据复杂
通过混合拼凑多个函数，来制造复杂程度，终究不是最合适的。
不妨把复杂转移到数据上，例如上述的 "hello~" 和 "world!"，如果换成更长、更没意义、更难猜测的数据，不也能制造复杂吗？
所以，最终可以把函数精简到只剩一个，取而代之的是复杂的数据，例如：
f(x) = sha256(x + "18bc0a594ab5f65d868820b238b696e391eabb962e1d15c2c474a04735c1128f")
这串数据称之为密钥。密钥是随机生成的，没有任何意义，并且绝不能对外透露。
这样，复杂程度就能在密钥空间上体现出来，而不是难以衡量的奇怪函数组合。
不过这里有个疑惑，为什么「密钥」加在原文后面，而不是前面、或者夹在中间？如果仅仅是看着舒服，那还是存在主观因素的。
HMAC
事实上，密码学家早已提供支持两个参数的 Hash 用法 —— HMAC，它比简单粗暴的拼接靠谱得多。于是上述可改进成：
f(x) = hmac_sha256(x, "18bc0a594ab5f65d868820b238b696e391eabb962e1d15c2c474a04735c1128f")
HMAC 第二个参数本身就是 Key 的意思，所以用在这里恰到好处。
当然，如果不保护好算法以至于很容易泄露，那么无论用奇怪组合还是这种方式，也都无济于事。
保护算法
很多人对算法保护的并不好，甚至直接写在了诸如 PHP 脚本里，只要有文件读取权限，就能搞到算法。
如果稍加隐蔽，例如通过本地服务，并控制好可执行程序的权限，或许就更难找到了。
更进一步，可以单独部署一台服务器，专门提供 HMAC 计算。通信接口足够简单，简单到几乎不可能出漏洞；并且不开放其他任何服务，只能人工管理。这样，被入侵的可能性就更小了。
当然，管理员人为泄密也是有可能的。如果要有一个终极方案，或许应该将计算交给一个独立的硬件。这个硬件是个黑盒设备，输入明文、输出 Hash 结果。算法、密钥这些都隐藏在其内部，拆开即自毁，这样管理员也无从知晓。例如 HSM（hardware security module）设备，就能将算法以及密钥进行物理隔离。
password |-------------------------|
----------->| 黑盒设备 |
| KEY = ***************** |
<-----------| hmac_sha(password, KEY) |
hash |-------------------------|
其他策略
如果算法能保证 100% 不泄露，那么加盐、慢 Hash 这些都可以省略了，因为密钥本身就足以对抗暴力破解。
当然现实中没有绝对的事。如果算法真的泄露了，现有数据的风险就大幅增加。所以本该有的策略还是得有，不能把风险全押在一个点上。
所以加盐、慢 hash 这些仍然是需要的。最终方案应该类似这样：
# 业务逻辑
hash = pbkdf(password, salt, cost...)
↓
######## 隐蔽的黑盒系统 ########
hash = hmac(hash, KEY)
##############################
↓
# 返回业务
这样即使黑盒算法遭到泄露，破解仍然需要很大成本。
破解成本
不过，奇怪算法也有一个优势，那就是破解软件支持程度不高。
传统的权威算法，早已成为众矢之的，有各种高度优化的破解方案，因此破解速度会非常快；而奇怪算法，则不在优化范围中，因此速度会慢的多。
所以，在权威算法之后，可以考虑再混合少量奇怪算法。这样，就能再增加一层破解障碍。
总结
-
奇怪算法是有意义的，但效果难以衡量
-
HMAC 的密钥需要足够长、足够随机、足够保密
-
保护好算法，和保护数据库同样重要