前端 js 混淆后加密提交参数，至少增加了爆破门槛

我可能有点敏感，不过我写的小项目也是用的方法 4 ，防重放肯定是做不到，但至少可以让明文密码不离开用户机（你说用户机被攻破了.......那算了）

😰 没有讨论的价值，服务器都破了。拿着你最高权限都懒得管你加不加密了

首先客户端的代码，花时间肯定能知道你的逻辑。
其次，服务器被攻破，花时间也肯定能知道服务器代码的逻辑。
因此，上面四种方案属于脱裤子放屁。

@Tstxxy  😂，很多人都是这样想的。

楼主我再告诉你 2 个案例，有人说 cookie 不安全，别人登陆你电脑拿到 cookie 就可以登陆你淘宝。还有人说家里的门不安全，因为你钥匙掉了，或者被偷了就会被盗窃。

你提出的问题 跟上面没啥区别。目前市面 95%的 app （ web ）都不会通过客户端加密来请求登录的（当然做了是更好），微信和支付宝虽然我没研究过，但是花 5000 块钱 肯定是可以拿到你说的那些啥前端加密的方式😂 。

有安全级别比较高的 app ，比如支付宝，他们就需要你的人脸识别，短信验证等。

这些逻辑都基于把密码当做用户隐私做安全措施，那用户隐私是什么级别的安全防护？当然明文存了。

在登入系统独立的情况下，密码可以由多个字段处理管理。
例如捆绑 ip ，换 ip 验证信息丢失。
验证器，例如谷歌等。
手机验证码，小金额保护。
人脸验证，大金额保护。

安全措施很多，不仅要只做密码一层。

4 感觉拿到 hash 后的密钥就能用 api 工具伪造请求，只是没有明文密码而已吧

服务器被攻破了，别人在下载用户数据，你却在破译用户密码

如果基于 Kerckhoffs's principle ，那么不能依赖客户端的服务器不被攻破，所以方案 3 和 4 是一样的。
搜索到 https://crackstation.net/hashing-security.htm ，这篇文章说得非常好，建议得方案比 OP 第 4 种稍作了一些变化，前端的 hash 函数使用标准密码哈希函数（例如 Argon2 、bcrypt 、scrypt 或 PBKDF2 ）而不是 SHA256 ，目的是减慢 hash 速度。