base64+https 就可以了，https 都被劫持了你的 js 文件是不是真的都是两回事，base64 完全是为了对付等保

上次有个等保扫我们，说我们所有的 api 路径都用了明文，无语，还专门写了个代码把所有的接口地址都改成\xx\xx\xx\xx 这样的写法

不知道你在说什么，就算攻击者得到用户的口令哈希，他怎么去构造请求登录其它站点？你该不会以前口令哈希是前端请求的时候构造的吧？

和 op 主几乎一样的想法和实现，用的方法 4 ，

https://nosub.net/posts/p/104

我见过的一个网站就是 每次先请求一个 rsa pubkey 然后用户密码加密后传到后端 反正后端有 privkey 解密..  存的话怎么存都行了 反正能比就好 很多成功例子

TLS 是传输层加密，传输层不可靠那就只能再往上一层那就是应用层加密了。
服务端的应用层那就是源码级加密。程序用私钥加密，通过启动器从环境变量加载公钥启动应用。这样即使攻破服务器也查看/修改不了源码，从而保护业务逻辑。
浏览器 -> 服务端则要求用户注册的时候保存用户的公钥，之后所有的请求需要用户私钥加密传输。服务端使用用户注册的公钥解密请求。这样只要保证用户注册时是安全的即可。用户的公私钥对要可以通过 yobikey 之类的东西实现。没错，就是以前的网银盾。

散列值+盐就行了，没有绝对的安全，增加攻击者的成本就行了

草，服务端都被攻破了，你还想着正经拿 post 内容构造？？？
直接改服务端插点 js 直接把所有用户动作上报不就好了，想要啥东西都给你传回来啊

@jinliming2 那啥，服务端就不应该明文存用户的密码，存明文密码有点窥探用户隐私的意思了

方案 4 比较有责任心, 不过大部分开发是没有这个心思的.

用户密码明文出现在服务端一侧, 就可以被社会工程学攻击, 以前就有过用户密码明文被日志记录的例子.

当然, 有人会骄傲地说, "你们日志不去敏, 你们不专业", 他们应该去看一下 "墨菲定律"

> Anything that can go wrong will go wrong.

服务端都被攻破，任何安全手段都是脱裤子放屁