@msg7086

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

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

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

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

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

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

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

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

> 如无必要勿增实体

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

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

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

@ZE3kr

> 首先用了 HTTPS 就不是明文传输密码了。标题本身就是伪命题

兄弟你应该是没有仔细阅读我帖子的内容, 请先读完再说这观点

> 老网站用 1 是历史遗留问题，1 升级到 2 必然是有成本的，不如直接升级到 3 和 4 。

其实成本不高, 主要成本应该是两方面, 一是客户端方面的, 比如原生客户端升级空档期, 而是服务端方面的, 比如用户量巨大不能短时间内全部更新成 hash 盐, 需要停服维护或者新增表项. 服务端的代码修改相对简单, 例如明文和 hash 盐都判断, 两个失败才算失败, 然后更新数据也可以跑任务分批完成所以不影响性能和业务.

> 而对于“不”注重安全的用户来说，你说的这些又有什么意义呢？人家根本不 care 。

@cmdOptionKana #11 在普通领域, 五十步笑百步确实没什么意义. 但工程密码安全这个领域一百步就是比五十步要强的, 建议各位看下 #7 @cndenis 说的纵深防御原则, 刚好 CF 上也有介绍, 这里面有 "加密" 的一段:
https://www.cloudflare.com/zh-cn/learning/security/glossary/what-is-defense-in-depth/

@cmdOptionKana #5

> 想做坏事的人拿到这个哈希值可以直接走 api 发给后端，这与明文有啥区别？

@cmdOptionKana 是有区别的.明文比 hash 具有更多的被窥探可能性，所以说的根本不是后续接口持有你的明文或者 hash 的问题。
至于拿到这个哈希值可以直接走 api 就更不太符合实际了，实际工程中多数不是每次带上密码明文或者 hash 去做校验，例如 web 前端，登陆认证通过后利用 server 返回的 token 、然后 cookie http only ，这种 token 具有时效性、或者再次登陆时旧的 token 失效。

@zhangjiashu2023 #78 明文本身也是存在问题的，hash 强于明文，hash+2FA 是强强联合，强强大于强，所以没必要因为有了 2FA 就用明文降级强度

@body007 看到 2FA 了，谢谢

@zhangjiashu2023 #75 看到了，谢谢

> v 站也有 2FA ，这是二次验证吧。

@body007 #1 在哪里，我没发现。另外，即使有、也应该是强制用二次验证才算是安全上起到作用，不启用的话就仍然强度偏低。但是 v 站或者其他论坛这种产品类型的信息不涉及资产之类的，所以还好，用户多站共用相同密码问题更大。

github 我不知道现在是不是必须使用二次验证了，好像也是最近哪一年才开始推二次验证的吧

很多人都是觉得：有人用明文，尤其是有大站例如 github 用明文，所以就是对的，根本没考虑过信道之外的安全，也没有考虑大站是否有额外的安全策略例如二次验证，也没有去统计对比，是不是所有大站都用明文、或者用明文的大站占据绝大多数，也没有去区别不同站的类型和对安全的需求等级，比如是否涉及资金安全的，例如金融类、电商类相关的接口

再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证？

@FTLIKON #1
github 的问题也不是没被暴出来过，类似 @YogiLiu #8 说的问题：
https://zhuanlan.zhihu.com/p/36603247

单就传输信道而言，https 能解决中间人问题，明文在这个用户前端到厂商之间的 https 信道范围内没问题。
单就 github 而言，因为有二次验证，所以即使拿到密码了换个设备也登陆不上，所以有一定合理性。但 v 站没有二次验证，用明文我个人观点不太赞成 @Livid

安全不只是传输信道，传输信道中间人之外还有社工、复杂的人生场景，例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码，以后说不定做什么坏事，这就属于传输信道之外的安全场景了。

用了 https 就明文只解决信道安全问题，用明文至少意味着：
1. 用户应该尽量管理好自己设备的安全
2. 用户到厂商之间的 https 信道之外的处理流程上，厂商应该确保安全，例如上面引用的文章里提到的 github 爆出来的问题以及 @YogiLiu #8 说的问题

另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失？
1. 成本：几乎没有增加额外成本
2. 收益：安全强度提高了
3. 损失：安全上没损失，但厂商不知道你明文，至于厂商知道你明文有什么好处，自己脑补吧

我觉得最大原因是很多人需要 OO, 而 golang 本身不提供 class 语法糖, 所以当需要 OO 的时候, 只能用接口来实现近似的功能. 但并不是所有东西都需要 OO, 所以接口也并不是必需品.

接口虽然不是 OO , 但本质上它们提供了相同的东西, 主要是多态, 各自有优缺点, 例如
OO 方便共用继承共用代码, 在很多传统领域多年架构设计已经基本形成了行业/领域范式, 比如企业级或者电商, 或者需求明确较少变更的场景以及即使变更也不大影响系统抽象设计的, 比如管理后台, 所以我们也看到, 实际的技术社区也正是如此, 在企业级和电商等领域, Java 这种 OO 加上社区保姆框架的 ** 语言大行其道.
OO 的劣势是前期抽象设计成本高, 对于需求不明朗和鸭嘴兽等 OO 不太好解决的设计问题场景, 以及需求迭代非常快很难在前期做好日后的整体抽象设计的场景, 因为变来变去的, 抽象的 class 系统想改动成本比较高.

接口 方便解耦, 用接口也能实现动态调用过程中去执行具体对象/OBJ 的方法, 接口比 class 也轻便, 多大的系统也不需要一开始就对整个系统做大量抽 class 系统设计, 日后需要修改也比较容易, 模块之间的交互, 接口也比 class 要更轻便友好.
接口 因为不具备整体的 class 系统, 所以读代码可能不像 class 系统那样一下子就把各种继承链之类的搞清楚, 但影响也不大.

整体上, 接口轻便灵活, 不管是 OO 以前就擅长的场景, 还是 IT 互联网高速发展的这十几年的快速迭代场景, golang 都能轻松应对, 而且性能也 easy, 普通开发者也不至于写出性能太差的代码.

我最好奇的是：python 和 java 都没有成熟的 json 库吗？为什么都需要开发者自己来实现解析 json 了。。。

技术人说话多数都比较直, 一不小心就闹矛盾了

@kenvix
如果写到多个文件, 每个文件可以自带上一个元信息, 即使任务中途失败导致下载器退出之类的, 以后还可以从上次下载的地方继续. 直接写入到目标文件, 没有这个元信息, 如果中途失败退出了, 下次只能从头来.
对于大文件低带宽不稳定, 不能确保单次操作下载完的情况下, 直接写目标文件不划算;
而即使是 10G 这种大文件, 本地多个分段文件做一次合并的开销和耗时也几乎可以忽略不计.

另外, 分段下载如果对方响应的数据不是 trunked, 而是 content-length, 不同平台或许还可以利用 zero copy 优化避免先读取到内存再写入文件, 既减少应用层内存开销也提高速度, 多线程直接写入 queue 再写入目标文件的方式不好做这些. 不过这些本地 io 和只是读写 buffer 的内存开销本来也不大, 即使能做提升也不会太大.

@ipwx #4 太贴切了