HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

[lesismal]

在隔壁 #71 #74 回复过了，但估计很难被人看到，所以单开个帖： https://www.v2ex.com/t/1043320

github 的问题也不是没被暴出来过： https://zhuanlan.zhihu.com/p/36603247

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

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

用了 https 就明文只解决信道安全问题，用明文至少意味着：

1. 用户应该尽量管理好自己设备的安全
2. 用户到厂商之间的 https 信道之外的处理流程上，厂商应该确保安全，例如上面引用的文章里提到的 github 爆出来的问题

另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失？

1. 成本：几乎没有增加额外成本
2. 收益：安全强度提高了
3. 损失：安全上没损失，但厂商不知道你明文，至于厂商知道你明文有什么好处，自己脑补吧

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

再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证之类的额外的安全策略？

[iX8NEGGn]

这根本就是俩回事。一个是：服务端是否应该保存明文密码；另一个是：是否在 https 下还要明文传输数据。请不要混淆。

[icy37785]

每次看到这种日经贴就难受，每个发这种日经贴的人都有一种错误的认知，就是认为前段加密或者哈希之后会更安全，至少也和明文同样安全。
但是却从来没考虑过，前端加密也好哈希也好，是有可能更不安全的，而连这种可能性都考虑不到的开发者，可以说会把这种可能性放大到无限大。
例如发这类日经贴的里几乎有九成考虑的是把密码 md5 之后发往后端，把不定长度的字符串弄成定长且仅包含字母和数字还不用考虑大小写的字符串，这不是帮穷举的哥们省事么。
看这类帖子越多，越觉得密码学第一章写得有道理。

[jianchang512]

前端加密会 hash 后肯定比不这样做更安全一点的

1. 可防止 https 信道不安全或被破解的问题
2. 可防止后端可能直接将相关信息输出到日志而暴露的问题
3. 可防止后端万一不做处理直接明文保存

当然作用可能微乎其微，大约类似心理安慰吧，何况有时后端也需要知道明文密码，比如后端也需要验证密码强度时

[tangmanger]

https 真的能解决中间人问题吗- - 再者 来自客户端的威胁几乎是不可避免呢 加密只是增加破解难度而已

[tool2dx]

@jianchang512 “比如后端也需要验证密码强度时”，这个验证应该放前端，前端又不是不能做。

用户给你产品付钱，开发者还是要对用户的密码安全负责。

[maggch97]

你跟 V2EX 上的大部分人讨论安全：大部分人会告诉你，你这个不是绝对安全，所以我用更不安全的方法也没什么问题。

甚至嘲讽你一句：做不到绝对安全还敢说安全？

[maggch97]

@maggch97 毕竟 99%的人的隐私不值一毛钱

[weijancc]

每次看到说要前端加密的, 都很无语, 发这种帖子说明你水平低下, 你电脑都能给别人装恶意软件了, 加不加密还有什么区别? 如果开发者知道加密的概念了, 那肯定不会在数据库保存明文密码.

上 https 对于安全的保障已经足矣, 你担心厂商偷你的密码, 那这已经是另外一个问题了.

[LnTrx]

@maggch97 关键在于要说明对安全的提升有多大。如果只有十分细微的提升，虽然也是好事，但是这样场景数量太庞大，会给工程带来不必要的复杂度。而增加的复杂度又会反过来增加风险。

[kyuuseiryuu]

你都已经假定后端是不安全的了，前端 HTML 不也是做后端的同一个公司的人做的吗，它怎么就更安全了呢？更何况前端代码是任何一个人都能拿到的。

对于社工来说，只要能拿到能登陆的那一串字符串就够了，他根本不在意你那串字符串背后的含义。前端加密唯一的好处就是可以给模拟请求增加难度仅此而已。

明文传输给后端不代表数据库里保存的就是明文呀。

通过配置 salt ，入库的时候混淆哈希完全可以防止被脱裤撞库的。

利用中间件也可以防止敏感信息被记录在日志里，这点就要靠开发者或者公司的规范来保证了。

前端加密方案面对的攻击者是用户本身，他攻击的目标是你网站的业务。

敌人都没有分清楚是谁一顿花里胡哨输出有什么用？

[kyuuseiryuu]

二次验证要解决的问题是“确认本人授权”。

如何保证就涉及到两个核心点

1. 动态验证
2. 仅本人可知

仅本人可知这一点需要验证设备仅被本人拥有。

动态验证需要设备产生的验证信息与服务端同步。

OTP 方案就是服务端和客户端使用相同的随机数种子，生成两端同步的验证码。

再就是公私钥对，自己保存私钥，公钥告诉服务端，服务端生成随机数给客户端，客户端加密后服务端用公钥解密。

以此来证明此时登陆的用户是拥有验证设备的“本人”在授权登录。

[pandaidea]

如无必要勿增实体

[fpk5]

> 例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码

假设客户端是不安全的那你任何的手段都没有用

[IvanLi127]

不相信服务提供商，请不要随意使用...没有信任居然提供自己的密码给他，还期望对方帮你离线加密，很离谱的行为。用户的使用环境不安全的情况下，就不应该用静态密码登录，你说的问题只是用户这边的问题，应该由用户自行解决。

而且你说的和密码都没啥关系，所有传输的数据你也应该要求二次加密，不然不是在裸奔么？这时候就不能 hash 了，得能互相解密，这样交换的密钥又是一个风险，然后咋办？再套加密？

[agagega]

二次验证防的是密码意外泄露，一般是指撞库这样的情况。TOTP/HOTP 协议从设计上避免了被撞库，OTP 密钥泄露的机会也非常小。

所以不发送明文密码只有一个正面意义，即避免服务端日志不小心泄露明文密码。但问题是服务端处理的敏感信息很可能不只用户密码一项，避免日志泄露密码应该从整个日志体系入手，而不是打补丁一样给密码做个散列就好。还有一点的话，就是散列后密码长度会变得一致，这样再做加密可以避免旁路攻击，不过服务器都能被人这么搞了，那整个网站也早就没有安全性可言了。

说这样可以让厂商不知道明文——整个网站的前后端源码都是厂商的，如果你不信任这个网站，那一开始就不应该去注册。

[jeesk]

@hefish
你确定是这样？
发送明文到 server ， 然后服务区解密， 那么是不是也有开发人员从日志里面拿到密码？

[NoOneNoBody]

这样做确实有个好处，就是即使服务器被爆了，用户真实密码也不会泄漏，只会泄漏一个“某种算法得出的伪密码”，爆指的是木马、submit data log 泄漏之类，不是数据库被爆（数据库存真实密码那就没什么好说的了）
就是类似 OP 说的第三点好处

厂商嘛，一个用户如何创建密码，也是这个用户 profile 特点之一，取决于厂商的道德观想不想知道这个 profile 特点了，咳咳
如果要防奸商，请使用随机密码，一站一密

说一下 2FA 的思想，2FA 基本上是用于“免频繁登录”的场景的，就是 cookies 驻留，对当前设备“简单信任”，2FA 就是利用另外的设备加强当前“信任设备”仍然在用户本人控制下操作。如果网站不采用 cookies 驻留，同时只有单设备登录，短时需重新登录的话，是没必要 2FA 的，以前很多，但现代极少再用这种策略了，因为用户体验很差，被时代抛弃了（例如之前某电商时不时就要重新登录一次）
2FA 并非加强了密码安全，而是加强操作安全（鉴别为本人），这里默认用户自己已经做了相应的安全措施，如果用户的账密和 2FA 设备是随便乱放、谁都能用的话，那 hash 万次也没用

其实按 OP 思想，最安全是动态密码，每次输入都不同（随时间变化），但服务端总能依据某个算法得出唯一结果作为鉴别，类似 TOTP ，但 TOTP 只有 6~8 位数字是不足够的

[NoOneNoBody]

对于附言：
再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。

===========
如果登录后，就基本不会存明文密码
对于上述行为，应该养成习惯，关闭 tab 甚至浏览器，再给别人用，ctrl-w 很快的
其实说到底就是对这个“别人”的信任度如何，不关就是很信任了
你应该从来没见过“老公把手机给老婆用时顺手关微信（也包括角色互换，无性别歧视）”这种情况吧？

[lesismal]

@cmdOptionKana #5

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

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

[lesismal]

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

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