超过三秒

@restkhz #87
我理解 OP 想避免被脱库，但增加脱库难度有很多方案，OP 偏偏选了一种“御敌 999 ，自损 300”的做法。我上面的说法就是在说这种自损是否值得。就没更好更优雅的方案了么？当然有啊，其中之一就是脱库者都不知道加密方式（未拿到软件系统），盐也不在 DB 中（算出来的），每个用户加密会根据用户本身信息而变（比如用户密码版本号），那对脱库的也是一种打击。

@forty
完全换另外一个算法的话，你就需要提前部署那个算法。否则 app 来不及适配，尤其是紧急安全事件，你得有足够窗口期提前安排。还是那句，搞这么复杂到底提升了多少安全性。

@forty #70
在是否能及时更新（算法）这个方面有很大区别。

匿名回复一下：不如真人好用。

@forty #66
“ 至于说要后端保存每种不同 hash 值的，完全不需要”

要不你再仔细想想？当然如果你说只限 web 当我没说。

@gamexg #54
其实没用，对于 CDN 来说，这个 Hash 过的密码也是密码，直接发给后端一样能登录。


@tool2dx #55
后端还可以将盐的算法跟用户名+版本号相关，这样有盐但不需要保存盐，只脱库没拿到应用的算法，破解者都不知道盐是什么（甚至盐会参与源密码进一步混淆），加大脱库难度。

@rxmt #47
有人问得好，安全要看你防的谁。

非对称你是要防传输层：
- 人家大可以给你一个假的密钥：你可以做证书认证 - 恭喜你发明了 HTTPS
- 传输层大可以直接换掉你的 JS 文件，跳过加密算法不更简单么

@iqoo #42
那问题可就多了去了，不同终端还得适配不对算法：我桌面软件不是 Jscript 写的怎么办？手表也不可能是 JS 写的，要动态加载 JS ？

如何确保这个 JS 是安全的，万一被别人替换了或开发不小心搞错配置文件直接改明文了。你返回算法名，如果我旧的终端当时还没有这种新的算法呢？那你得提前更新新算法到终端，否则终端不支持。

还是回到那句话：你做了这么复杂的方案，安全提升了（或降低）几个百分点？是否值得？

@tool2dx #39
“现在的 hash 和以前的 hash 不一样了"

你看吧，Hash 也有新算法，也就是说你永远没办法保证现在的 Hash 算法就是最佳的：这就意味着哪天你会需要升级前端算法以保证安全（不会被迅速脱库）。又回到我上面说的：如何确保不同终端一并更新，而且你的新算法还得考虑到不同算力的终端（从 PC 到手机再到穿戴设备）。而且你的前端算法还是公开的。

所以，为什么不定期更新后端密码落库的算法呢？这个百分百可控，不影响前端，任你随便玩，你还可以将应用和 DB 分开，这样只拿到 DB 不知道应用里的参数（比如这个 1000 万次 Hash ），是没办法彩虹的。不更好么？

@iqoo #35

用户名可以被扫描了：安全值 - 1 。

另，哪天 Sha256 不安全了，你需要换个算法，你一样会遇到上述问题。你为了避免被脱库，将算法固化在了前端，导致后期修改比较复杂，这个算是得不偿失的方案。

@iqoo #27
你没明白我说的，我说的就是升级的时候发生的事情：只要你没办法统一升级客户端（让他们一致使用新的难度），你就得保存难度的 Hash 过后的密码，否则其他难度的登录请求你没办法验证。

@iqoo #24

或者，你的方案本来执行得好好的，哪天老板脑子抽筋说某个穿戴设备也需要对接。

手表上跑 1000 万次 Sha256 ，额。

@iqoo #24

那你的方案会带来密码碎片化：只要无法做到所有终端一起升级，服务器就不得不使用原密码将每种 Hash 都算一遍保存起来，否则还没来得及升级的终端的登录将无法得到验证。

@iqoo #22

又多一个难度值的概念，请问你做了这么多操作，将安全提升了多少？有 100%提升还是 1%还不到？

@chingyat #18
就算没有多个版本，你现在需要升级算法。但：你有网页版和 APP 版，前者容易，后者你都不一定能限定用户必须使用某个版本的 APP 。你直接停掉之前所有版本的 APP 强迫用户升级？还是你做兼容（意味着保存多个密码版本）？