密码设计问题

今天看掘金文章，看到一篇 Node 写的毕设项目 100 人并发就撑不住，我是这样解决的 的评论给了一个很有意思的观点：

一般这种情况都是将 hash 工作交给前端，最后数据传递只传递 hash 后的密码。有人可能认为，如果由前端进行 hash，会导致 salt 泄漏之类的情况，但是实际上，salt 泄漏并不会带来问题。salt 只是为了防止相同数据的 hash 碰撞问题，只要你设定了独特的 salt，不会和其他被脱库的数据集采用了一样的 salt，就不会由有问题。还有人会考虑，如果泄漏 salt 有可能导致可以本地生成字典 hash 进行碰撞。其实这个情况也不用担心，节流阀等东西可以做好限制，而且如果别人铁了心要攻击了，估计会开大量代理来反复撞库，可能密码还没破，网站先挂了。总而言之，这种可以由客户端解决的任务，可以交给客户端来处理，既能降低服务端的负载，同时也不会丢失安全性。

以上的说法我还是认同的。

其实在时候很多大公司的 API 时，也会经常看到需要调用方先对 key 或者 password 进行 hash 处理。甚至在写很多网站爬虫的时候，也是在前端进行 hash 后再调用登录接口的。

后端服务器一般不会存明文密码，所以在注册，更改密码的时候，后端也只需要经过 hash 的密码即可。而前端也不会保存密码，如果使用的是想 OAuth2.0 的方式调用接口，密码其实在后续的接口调用中没有任何作用。如果做记住密码的功能，则需要保存在前端。不过现在的浏览器都自带记住密码的功能，不实现其实也问题不大。