@iyaozhen #154, 或者我的所有楼层的 key point ，与之前好多帖子讨论为了安全需要 HTTP 不允许使用 PUT 是否合理类似。

很多人看问题喜欢抓几个点，例如：
1. 这个东西可以这样用，用对了没问题
2. 这个东西有大厂再用
3. 大家都这么用了这么多年，你认为不好你 sb

但是这帮人很少考虑过更全面的关联的东西，例如：
1. 除了他自己负责的链条环节，其他关联部门工种的环节
2. 可以这样用就是最好的方案吗？
3. 工程上的其他替代方案是否更好，或者说替代方案有没有增加成本？

前面有位提到“如无必要，勿增实体”，我也回复过。这个原则很对，但首先得想清楚，这个地方是否“无必要”

@iyaozhen #154

我的观点一直没有说 不用明文能避免一切隐患，而是说，要避免完整链条上的，例如爆出来的 github 后端日志以及其他公司也可能有开发者“不小心”这样做。

我在 append 里也有说：
```
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴

你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
```

所以你们各位说的这些重放也好，https 信道也好，都不是重点，因为这只是我说的 3 个 part 中的 1 或 2 个而不是全部，hash 解决不了重放的问题，明文解决不了前后端泄露的问题，各自有各自解决不了的问题，所以如果业务安全级别要求高，就应该努力提高每个环节的安全强度，尤其是这种本来就可以使用非明文且不需要太高成本的场景

> 本来以为开个帖是和大家一起讨论的，结果只看到过强的主观意识

我的 "过强的主观意识" 都有对应的场景和逻辑解释, 所以是就事论事讲道理. 我没有看到你列举这些, 包括 #22 提到的, 你都可以在我的帖子或者 append 和回复中找到对应的逻辑, 但是 #22 有逻辑吗? 如果有, 兄弟你能回答下 #42 吗?

@agag 请拿事实和逻辑说话, 不要随便给我扣这种你门以为的我是 "主观" , 对比事实和逻辑, 再来说咱们谁更主观谁更客观

@iseki base64 肯定不算是哈希或者加密的 key point, base64 最多用来把 hash 或者加密后的二进制弄成 text 用下

想入门通俗易懂快速上手, 就看 图解密码学 吧, 看完想深入再挑学校课程或者类似密码学理论的书都可以

@wtfedc #138 和 好几个 append, 阁下先读下

@belin520 10 年前这个事情, 没人说打标签的人是对的, 所以你得到的结果和结论也不一定准确. 如果觉得当初没必要做, 那可能是 10 年了自己被打标签的人耽误了所以没进步.

@csrocks @iseki @kiripeng

这个帖子主要意思是完整流程链条安全的更强, 主要解释的是之前帖子里对于明文的分歧, 明文这个问题, 哈希加盐就可以了, 想更强的防碰撞就上更强的 bcrypt 或者非对称加密.

加盐方式方式根本就不怕暴露, 因为是散列或者用非对称加密, 你知道算法也解不出原始密钥. 很多人杠说直接拿着哈希盐去请求也一样, 说的没错, 但是也比直接知道你原始密码在网站上操作要麻烦, 因为他要去分析前端代码然后再去写更多代码, 包括各种应对反爬虫各种.

非明文至少解决一部分前端和后端流程上的直接拿到原始密钥的问题. 正如我前面都讲过的, https 只解决信道问题, https 信道之外的 client 和 server 流程上, 它解决不了. 所以这帖子根本就是不是在讨论 https 信道本身的问题.

任何技术手段都不能完全防止被破, 因为还有社工的可能. 但至少增加破解难度, 难度的提高同样能让很多破解的人失败, 又不是所有你遇到的都是顶级黑客, 所以至少降低了被破的概率.

@maggch97 确实, 很多人挺专业的, 但只盯着技术本身 1 两个点, 然后说这个也没用那个也没用, 就不能去考虑下除了技术这个点之外的更多场景

> 此外再提及一点，许多密码基础设施提供的验证接口形如 verify(password, stored_credential) -> ok?，这里虽然没有明说（实际上也不可能要求） password 必须是用户的原始主口令，但一般确实可能影响到实践。

@iseki 有人这么做, 不代表这么做更好

看一下我新 append 的, 不是只局限在技术范畴算法范围内考虑安全的, 暴出的 github 那个例子就是这种情况
明文相比于非明文至少是提高了一点点强度的

> 说本地木马：跟明不明文已经没关系了，咋不说键盘记录器呢。

@dzdh 这个我也解释了啊, 木马只是举的一个例子, 实际考虑的是所有可能情况不只是木马

> 既然你是明文传输，那你绝逼往日志里写密码了，还特娘的是明文。你特娘肯定数据库里存的也是明文！！艹！

我没说过这话, 没有推断别人一定作恶. 但是你用明文, 就存在这种可能性. 算法复杂度讲究考虑最坏的情况, 安全也应该在能力范围内尽量考虑去对最坏的情况做防护, 有错吗?


看你几楼的回复, 感觉我说的啥你都没 get 到吧兄弟

> HTTPS+明文的，你倒是不看是吧。

@dzdh 我用亚马逊淘宝, 是针对坚持明文没问题的人, 是举反例, 因为按照你们的逻辑, 就不应该有技术级别足够高的厂商使用明文因为这样做太傻逼了, 我举例是反证法的逻辑. 所以我没搞懂为啥你好意思来反问上面这句

多加强一道更安全一点不是错, 你举那么多用明文的只能说明他们加上其他的验证方案也有很强的安全级别, 但不代表比不用明文的安全级别更高.

> 你前面帖子里说的是老网站用 1 的问题, 所以我只解释解决 1 中用明文的问题的成本, TOTP 这些都是属于密钥本身格式之外的, 不管密钥用明文还是哈希盐, TOTP 之类的这些都可以加, 所以这个成本不应该用来对比密钥格式本身的成本.

@ZE3kr 我不确定是否有误解你 #13 的 1, 因为你说的是密码, 没说是明文密码, 我快速扫内容以为是按照主题在聊密码用明文相关的. 但是你的 2 中有说 HTTPS+前端加密的 跟 1 一样不安全, 所以 1 中应该就是指明文密码, 否则 1 和 2 就一样了, 我有点迷惑. 另外, 这里 2 中通常不是加密, 密码不会太长当然加密算法也能用, 但通常是 hash 指纹这些

@night98 #20

> 3.服务端安全 现在基本上都标配 Bcrypt 了吧

Bcrypt 可不一定是标配, 这玩意防爆破拿手但是成本高

同样的, 我就想请教下, 为什么淘宝亚马逊不用明文

> 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
> 因为这才是正确的路线。放弃密码，不要用 what you know 而用 what you have 。

@msg7086 这个正确路线有前提, 要有 app 已经设备认证过然后能扫码. 否则 SMS OTP 或者加上两步验证之类的才安全, 事实上很多大站也确实加了两步验证, 但他们照样也不使用明文, 比如淘宝.

所以我也请各位再看一下我 append 里面的, 为什么很多大站们不用明文. 不要用 github 用明文来反驳了, github 非金融类的安全级别要求算是偏低的了而且因为这明文被爆料过的

@msg7086

> 1.为什么成本没增加。

一个哈希盐算法, 设计初期就用上的话也不涉及日后把明文升级哈希盐水, 所以就是初期前端的一层包装, 这个成本你给我说有很大, 那我只能表示佩服了

> 2.增加到什么程度才够？
> 就比如你说的多加一步加密没有成本，那为什么只加一步加密，为什么不加密两次，加密三次？为什么没有成本的加密只做一次。
> 如果加密多次也没问题，那么加密五轮就够了吗，还是五十轮呢，或者五百轮？

清醒点, 这里说的是流程上的明文 vs 哈希盐, 你用什么哈希盐算法是你自己的事情, 里面加密多少次是你自己的事情, 但是对于明文->哈希盐的流程只是一个步骤

你说这个一轮流程加密多少次, 就是硬杠了

@ZE3kr #48 标题确实, 我在 append 里有解释了. 因为引用的隔壁帖子, 都是关于 https 载体之上的, 这个帖子起标题时没注意标点符号导致了你的误解, 但是内容上, 并不是在说 https 本身是明文, 我本身也强调了 https 解决中间人

> 你这里列举的成本就已经比 TOTP 高了

你前面帖子里说的是老网站用 1 的问题, 所以我只解释解决 1 中用明文的问题的成本, TOTP 这些都是属于密钥本身格式之外的, 不管密钥用明文还是哈希盐, TOTP 之类的这些都可以加, 所以这个成本不应该用来对比密钥格式本身的成本.

> 如无必要勿增实体

@pandaidea 这句话是对的. 安全场景不是"无必要"

> 但是却从来没考虑过，前端加密也好哈希也好，是有可能更不安全的

@icy37785 因为是跟明文做对比, 所以我认为你这个观点是指 前端加密哈希后可能比明文更不安全? 请教, 什么情况下会比明文更不安全? 因为我暂时想不到例子