感觉就这点钱，也没啥好割韭菜吧。
我只知道我买的合资被割了...

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

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

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

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

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

同上海，我买了个..