密码设计问题

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

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

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

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

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