@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 强迫用户升级？还是你做兼容（意味着保存多个密码版本）？

@iqoo #15
假如有 N 个版本呢？还得记录每次用户的密码？或者 N 个版本所有终端不能同时升级到最新版，那么有的旧版的终端怎么办？

不管你怎么算的，都可以将算的结果认为是“密码”，服务端认这个“密码”就得。

当天强度不够了，要升级：服务端没办法认新的算法了吧？必须得强迫用户重置密码？

如果担心噪音，可以先试试自通风是否足够：原理就是热气上升。上下边各开个孔。

@mrleft #96
这个道理很简单：大批量生产成本才会低，型号越多就越不利于大规模生产。生产厂家觉得“只生产少数几个型号，其他的要么屏蔽要么看良率降级”这种方式对他们来说最优，这样生产出来的产品直接就可以按市场需求出货，不会因为某个型号需求激增生产不过来。

为什么不降低价格？因为 16g 的你降了，总有用户觉得 8g 就够应该更便宜而厂家觉得再开一个型号的成本高于直接屏蔽 16g 一部分。

还有 4g 就够的学生本儿，怎么办？

这种只为了吸人眼球的 up 主我劝你少看，他肯定知道为什么但他故意引流。其他话题他也会同样操作，长此以往你能收获什么？亢奋的情绪？

信创，自主。

试试让它输出 PPT 文件的 Base64 编码给你。