CloudMx

后悔倒是不后悔，冤倒是很多，就不细说了，哈哈哈。

把 iphone12 换成了 14pro 的时候，高刷屏幕很爽。

@busier 防止中间人是 HTTPS 的事情，没问题。

如果在没有中间人攻击的前提下，密码我还是建议 HASH ，理由之前说过。
其他的敏感信息，你可以 RSA 这种非对称，反正现在的机器配置不低，在传输数据量不那么大的情况下，性能没啥问题。

@BeautifulSoap 前端后端同一个写的，在我遇到的情况现在很少，很多不是全栈，他们都是对自己方便用什么方式。

你如果想说的是安全是一个整体，我肯定是赞同的。

为什么说到前端信任这个问题，因为你说前端也是不安全的那真就没有解法了，你总得输入明文密码，也就不需要说 HASH 再传输到后端了，你无论咋处理，明文就是可以前端拿得到。

我也同意你说的没有多少用处，上面我就说过了，它的用处就是出了浏览器传输开始到后端，没人能知道明文信息了。

@BeautifulSoap 没有，我就是一直在说的是“我不同意 HASH 后传输是脱裤子放屁”。

如果要说 HASH 跟不 HASH ，对于后端登录来说，它本来就是没有什么两样，它只是去验证是否一致。其他人获取了如果没有添加 nonce 的，重放肯定是可以正常登录的。

你如果都说有主观恶意了，它其实什么都是不安全的了，你总得在前端输入你的明文密码，就像你说的，这里你如果不关注就算 websocket 发送出去你也不知道。

我的论点就是，在其它都不关注的情况下，HASH 后的密码值传输到后端，比加密到后端更合适，所以我说“我不同意 HASH 后传输是脱裤子放屁”。

HASH 传到后端的目标就是一个，从浏览器传输出去后，就没人能够拿到明文信息。

@BeautifulSoap 而且你这主要是考虑登录问题，我这边的角度是不想后端知道我的明文密码。
还有你说的 100 次，其实有啊，pbkdf2Hmac 这种。攻击者要想跑字典得花更多的时间。

@BeautifulSoap

你说 HASH 化后的密码可以登录，这个是毋容置疑的，后端接收后就是验证这一串值的，你后端看见的就是你说的“明文密码”，它只要去跟数据库里面的去对比就行，不管你是什么。

但是我这里表达的是，我前端 HASH 后，你后端接收是不可能反推出我的明文的，但是如果你用加密方式，你是有机会的，谁知道你会不解密我的密文干些啥。

你说的在哪一步好，我的建议是方法 2 或者方法 3 ，理由就是上面说的，我不想也不愿意你存储我的明文。

方法 1 跟方法 3 有区别，方法 3 后端永远不可能知道我的明文。

方法 2 跟方法 3 是没有什么区别的，硬要说就是双 SALT ，一个前端 SALT ，一个后端 SALT+前端 SQLT 。对于攻击者来说，要么中间人的时候获取到出来后的 HASH ，直接跑字典，要么获取到数据库查询权限后，获取到对应的 HASH 值以及后端的盐，前端的盐默认就是公开的(这里不考虑中间人直接插 JS)。

任何密码信息，都不应该存储明文、加密存储，而是 HASH 摘要存储。除非你说你要在后端验证密码复杂度。