@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 摘要存储。除非你说你要在后端验证密码复杂度。

@BeautifulSoap 有啊，我想说的不是明文，而是任何加密形式的密码保存都不应该存在，密码对应的只能存储对应 HASH 。你非对称也好、对称也好，都可以解密。HASH 这种，稍微加点盐，你就只能自己跑字典。

@flyqie 就是密码这种东西，根本不需要传输明文到后端，不管你业务怎么使用，比如：验证密码，历史密码记录等。不可直接"逆向"成对应明文它最大的意义就是这。

使用 RSA 也需要防止中间人，这些都是相辅相成的安全策略，应对不同的攻击方式。
我不同意 HASH 后传输是脱裤子放屁，因为密码这种敏感信息数据库是没必要存储明文信息或者加密后的信息的，只需要 HASH 后，存储，不管你从什么业务考虑。HASH 摘要算法你到后面的攻击方式想要对应的明文，无非就是去查字典或者自己生成字典跑。

不管怎样，密码这种信息都不建议使用加密方法，而是使用 HASH 摘要算法进行处理后进行传输、存储。
它不需要“解密”还原成密码明文。

同上海，我买了个..

这个价位你想买 BBA 的牌子直接买就行了,虽然优点不多.

我是来看评论区的，嘿嘿

假的.

原来并不是老百姓真穷？老百姓还真是有钱买房子啊，哈哈。

看起来是获取了所有中间通信的值，包含密钥，不可能单单能把密钥算出来。

感觉就是扫描器在扫你们...