@livin2 #186 对, 对于老项目是这样的. 但对于新项目可以避免这些

@LuckyLauncher

> 电商领域有没有可能考虑的不是安全性而是反爬机制

都重要

> 你看看他们的风控就知道了，以前淘宝的风控被诟病成人类都无法使用。

这反到可能是因为他们反扒导致功能上频繁让用户验证导致用户诟病, 如果只是设计正常的登陆反倒可能不至于被诟病, 我用淘宝不多, 所以也不能确定是怎么回事

> 当然这只是我的猜测，至于厂商为什么选择加密只有他们做加密的人知道了，可能亚马逊和淘宝选择加密的理由还不一样。

不要随便猜了, 就不能看下我这么多发言的内容吗, 但凡大家能用冷静分析的态度来思考这个问题, 而不是一开始就拒绝观点, , 也不至于这么多人还坚持明文了...

我琢磨可能是因为, 很多人自己这样用了习惯了, 所以这是属于舒适区, 人的天性就是难以从舒适区里出来
加上经济学上的"沉没成本效应", 因为自己学习领会了一些 https 和加密相关的知识, 就使用这些知识点头疼分析头脚疼分析脚, 只管自己处理的环节, 从而忽略了整体流程上的完整安全

@qq135449773

> 二次验证防止的是未经授权的用户登陆操作，防止的不是密码泄露。

我也没说二次验证是防密码泄漏啊，就是因为密码（不论明文不明文）都可能泄漏，所以才要二次验证这些额外的打补丁。但不是说有了二次验证密码就可以不在乎了，否则还要密码干啥，都走 SMS/EMAILS 之类的 OTP 登陆更省事了但用户又说你强行要我私人手机号了。。

> telegram 和 whatsapp 这类东西，包括微信，做扫码登陆，因为他们本来主打平台就是移动端，只是顺便做的其他平台而已，所以才敢这么做，至于安全与否完全只是顺便而已。

是不是顺便我不知道，但安全问题，如果安全级别要求高，我们不应该用“顺便”的方式来思考

> 给密码再加密一层，密码是安全了，返回给用户的 session 你也要加密返回给用户吗？

例如 JWT 吧，它确实是 server 加密后返回给 client 的，你的用法或者理解是不是有什么误会


> 像 CDN 、WAF 这些做 tls offloading 的东西，还有一些其他公有云设施，这种东西你只能默认信任。
> 假设你以上所有东西都 ok ，你怎么确保你公有云 instance 的云盘或者云数据库不会被未经授权的读取？

同样的，你的这些观点就像我回复其他人的以及 append 里讲的一样，不要只关注我所说的一两个 part
用别人服务默认信任、别人也应该尽量提供保障，这个我没有否定过
重要的是，各个流程链条上，各自尽量做好自己环节的事情，三方厂商做好自己这一层，出了问题它是要赔钱的，我们不能确保三方一定不出问题，所以自己方负责的链条也做得安全强度更高，有错吗？

> 所以就不要自己骗自己了。

这句话我建议你先送给自己，然后好好看下我、以及与我持相同相近观点的各个楼层或者其他地方的知识点

@bullfrog 要是想聊技术问题, 就正经拿出你的技术观点聊, 这种戏谑的例子跟帖子内容基本没有关系, 习惯了这种不去真正思考只喜欢戏谑的思维方式, 只会成为兄弟你技术进阶的阻碍. 当然, 如果家里有矿无所谓技术进阶, 那你随意, 我也不 care 这些

@wanguorui123 #100 完全同意, 就是应该在各个层级尽量做好. 好些坚持明文的在这用自己做了五十步的安全笑别人百步, 我感觉他们就是因为明白了一些算法本身, 然后只思考整个环节中的一两个环节从而忽略整体, 可谓是头疼医头, 脚疼医脚, 不管全身

> 就拿我司我们 org 的习惯来说吧。如果你要做一项比较大的功能改动（你说的前端加密就已经是比较大的改动了），一般需要先开一个 wiki page 把改动写在文档里。

@msg7086 我现在明白一件事了, 因为你门大部分人的项目, 本来就选择了明文, 如果用户和业务量非常大, 即使改造方案没问题, 但也是担心规模效应, 所以确实成本大. 但我们并没有局限于旧项目改造, 新项目如果从一开始就应该使用非明文方案. 如果你们团队一开始就明文了, 那说明最初负责技术的人本身他就不够严谨

> 从我读你帖子和回复的内容来看，我并没有看到（ 1 ） HTTPS+明文这样的设计会造成很大的经济影响（例如大规模密码泄露，账号被盗等等），（ 2 ）你设计的解决方案会产生什么样的经济影响（例如原本 v 站大量账号被盗，经过你事故分析，确定是明文传输造成的，如果做了你这个方案，账号就不会被盗了等等）。

你有没有想过, 很多黑产搞到东西, 但每年我们看到的新闻有多少? 被你知道的泄漏了的只是冰山一角, 你没看到不代表明文就安全了, 也不代表改造后就没带来更全的安全性.
另外, 黑产最高级别是社工, 从企业到政府国家之间的渗透, 很多技术上安全做得非常严谨的仍然被渗透过就是通过社工, 比如后端开发假装失误把日志里打印出了明文的用户信息并且盗取出售, 事后即使企业发现了整改了, 后端内鬼也只是说不小心失误了, 你不能保证所有项目所有流程都严谨, 即使流程都严谨, 也不能保证执行过程中完全没有疏漏.

前阵子那个压缩算法开源项目贡献者潜伏成维护者然后投毒热度刚过, 不要没被烧伤就不知道疼, 不要好了伤疤就忘了疼

> 你就不能推进网站后端采用 bcrypt 或更安全的验证算法，推进网站后端 log 脱密记录？

@viruscamp
bcrypt 本身也是非明文的方案之一, 我没有抵制过使用 bcrypt, 是否采用 bcrypt 的阻力有两个, 一是团队有没有人懂安全, 二是 bcrypt 性能, 所以 bcrypt 也就回到了大家都比较认同的安全级别问题上了. 对于 FIN Tech 相关的安全级别要求高的, 用 bcrypt 即使登陆的时候慢那么一点点也无所谓, 但是对于安全级别要求不那么高的并且并发量在线量大的, 可能就不会采用 bcrypt

至于后端 log, 这个我相信多数团队都有要求, 但是你没办法避免开发人员或者有心之人假装无心 log 打出来了, 再采用明文的项目里, 这额外需要严格的研发流程把控, 而如果本来就没采用明文, 就不需要这个额外的流程把控, 你觉得哪种更划算?

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

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