0x00 前言
加密算法越快，破解起来就越容易。加密时多花一点时间，就可以换取攻击者大量的破解时间。加密越慢，破解时间越长。「慢加密」算法例如 bcrypt、scrypt 等等。它们都有一个难度系数因子，可以控制加密时间，想多慢就多慢。
但慢加密也有明显的缺点：消耗大量计算资源。使用慢加密的网站，如果同时来了多个用户，服务器 CPU 可能就不够用了。要是遇到恶意用户，发起大量的登录请求，甚至造成资源被耗尽。
性能和安全总是难以兼得。有没有什么方法，可以让我们使用算力强劲、同时又免费的计算资源？
0x01 前端加密-慢加密
在客户端拥有强大的计算能力的今天，前端加密逐渐被重视，分担一些服务器的工作，尤其像「慢加密」这种算法开源、但计算沉重的任务。而且前端密码传输过程中如果不加密，在日志中就可以拿到用户的明文密码，对用户安全不太负责。
TODO:慢加密过程流程图：
破解慢加密之预先计算：
但是前端的一切都是公开的。所以 front_slow_hash 的算法大家都知道。
攻击者可以用这套算法，把常用词组的「慢加密结果」提前算出来，制作成一个「新字典」。将来拖库后，就可以直接跑这个新字典了。
对抗这种方法，还得用经典的手段：加盐。
0x02 前端加密-加盐
确保要往每个密码里添加随机的唯一的盐，而不是让所有密码共享一样的盐，即可对抗前面提到的这种常规的暴力穷举字典破解方法。 这样，即使相同的密码，对于不同的用户，「慢加密结果」也不一样了。
1
2
3
4
5
6
// 前端生成盐值
salt = rand()
password = front_slow_hash(password + salt)
// 提交时带上盐值
submit(..., password, salt)
0x03 前端加密-定期更换盐
参考文章：
还没看 https://github.com/Advanced-Frontend/Daily-Interview-Question/issues/150
web前端慢加密
前端动态加盐慢加密方案图解