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+明文就安全了，为啥还要有二次验证之类的额外的安全策略？

[InkStone]

@zhenjiachen

你前端都使用 bcrypt 了，还多此一举把明文传给后端干嘛？当然是直接把 nonce 和 hash 传给后端啊。

主要是你的思路实在太奇怪了，从头到尾除了你就没人说 aes ，就算要加密口令也不可能脱离 tls 单独用 aes 。不赞同用 aes 听起来就像不赞同裸 http 明文传递密码一样，不赞同了个寂寞。

[JoeDH]

现在越来越多的网站首推的都是扫码登录、短信登录了

[zhenjiachen]

@InkStone 我没说你前端用 bcrypt 还需要传明文给后端啊，我说的是你前端传了 bcrypt 哈希值的话，后端怎么和前端传过来的哈希值对比，因为 bcrpt 的特性就是每次都是不一样的字符串，所以后端只能保存明文是不是？

所以根据以上结论就是前端使用哈希密码的方式传参数是对后端密码不安全的，所以只能使用对称加密或者非对称加密的算法，所以我之前的说法只是拿 aes 来举例而已。

[maggch97]

楼主你这么想，很多人还处于刚刚认识到，哇原来 https 能加密呀的阶段。后续的数据库，日志是否安全，不加盐 hash 和加盐 hash 泄漏后的影响区别已经超出大脑思考的能力范围了

就像你在哔哩哔哩发一句差强人意，一定会有茫茫多的人来当你的语文老师一样

[lmhsmart]

在系统复杂的情况下，鬼知道哪里就把密码 print 到日志里去了
另外，这不仅仅是技术问题，还能避免被人恶意黑，譬如截屏 network 黑你的产品是明文的有安全漏洞，辟谣得跑断腿，而且群众还不信。加个密不就是举手之劳么，有什么大工作量吗？

[qq135449773]

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

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

> 为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?

我猜测可能是因为亚马逊淘宝这类网站是逐步从 http 过渡到 https 的，他经历了没有 TLS 的时代，所以需要手动在 payload 里去加密 sensitive 。

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

我的一些观点：

像 CDN 、WAF 这些做 tls offloading 的东西，还有一些其他公有云设施，这种东西你只能默认信任。

为什么这么说？

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

你收到一个加密的 session ，你怎么判断这个 session 是用户发的还是恶意构建的请求？

假设你以上所有东西都 ok ，你怎么确保你公有云 instance 的云盘或者云数据库不会被未经授权的读取？

我并不是说以上问题没法解决，我想说的是，如果你要确保你想的那种 level ，绝对不是给密码再加密一层密码加密就能解决的问题。

架构设计本身就是一个不断做取舍的过程，这个问题上的取舍绝对不是这么简单就能解决的。

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

[qq135449773]

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

用户登录过程中因为 996 过度，猝死了，你也要在代码中设计一套逻辑防止用户猝死吗？

不要为用户的行为买单，我们的目标人群是 90%的正常人，不要为了那小部分不正常人的行为花精力。

[justdoit123]

密码（或者 hash 过后的密码）终究要出现在内存里，云服务提供商是不是能从内存里直接读出密码。

安全没有绝对，做到什么程度，看被保护的对象是什么，需不需要做到那么高的层级。

服务端发一个公钥，然后在客户端把重要数据再自己加密一次也不算很费事。不过不加也就那样。


> 密码是用户自己的隐私，不想让服务提供商知道我的隐私。

我感觉这种想法很美好，现实是你这种“隐私”会像乐色一样被对待。不想泄露隐私，绝对的安全就是把自己关在一个盒子里。 当你使用服务的那一刻，很多“隐私”都已经不复存在。真那么觉得 密码 是一种隐私，那用户名（ email 等）也应该是隐私。以后要用这些东西，就每个服务都用一个随机 ID 、随机密码。这样就不会泄露“隐私”了。但是真的好累。

[unco020511]

https 明文传密码是安全的

在普通应用领域,谈安全有两个前提:
1. 用户认为自己使用的客户端是安全的
你会在自己认为不安全的机器上使用需要安全保障的服务吗?当然不会
那么你在自己电脑上安装木马,或者你自己安装抓包工具且手动安装证书,然后将抓取到 https 的密码共享给他人,这些是安全问题吗?是,是用户自己的原因.


2. 用户信任应用的服务端
你用这个应用,这个服务,那肯定是认为他的服务端是安全的吧,明知道不安全还用吗?

综上,所以对于开发者来说,安全问题实际是链路传输的安全问题,https 的出现不就是很好的解决了传输链路的问题吗. 口令本身是完全安全可信的认证方式.

那么对于问题 1,虽然用户认为自己的客户端是完全安全可信的,但总有一些其它因素会泄露口令(社工,用户主动行为等等),那应用开发者就只能再加一些认证,此时 2FA 就出现了

[lifei6671]

@cmdOptionKana #9 op 的意思是说，明文密码不应该让 V2EX 服务端拿到，如果他拿到了明文密码，大概率你所有的互联网账号都不安全了。如果 V2EX 拿到的是多次 hash 后的值，泄漏了无非是 V2EX 不安全，不影响其他账号。

[leonshaw]

看来很多人对安全认识只有 0 和 1 ，也分不清攻击面在哪里。

[Nosub]

我个人博客的密码设计思路，可以参考一下：

前端：对密码做 hash(psw+salt)->hashPsw
后端：对 hashPsw 二次 hash （随机盐+hash 算法）；

设计原则：后端不依赖前端的加密逻辑，就是无论前端传递明文或是 hashPsw ，后端该怎么处理依然怎么处理；

第一层防护，HTTPS 保证的传输过程中的安全
第二层防护，用户的密码，提交后就进入了加密状态，即便第一层 HTTPS 防护失效，或是因为部署环境的限制只能走 HTTP ，日志，或是网关服务，数据转发，也不会被中间人窃取明文密码；
第三层防护，数据库保存时候，通过随机 salt+Hash 算法，保证后端人员无法查看用户原始密码，保证服务器即便被黑，数据库泄露，用户的原始密码依然是安全的。

简单来说，当注册/修改密码到数据库后，程序的设计者其实也无法知道用户的真实密码是什么；

https://nosub.net/posts/p/104

[thursday]

op 的意思是说，明文密码不应该让 V2EX 服务端拿到，如果他拿到了明文密码，大概率你所有的互联网账号都不安全了


不信任任何一个网站，那自己加密得了，那就别用统一密码。

希望各网站 前端加密 不明文传输给后端 和 希望各网站后端加密不明文存储 。

其实是一个事情。实现后面的这个就够了。前面这一步意义过小了。
如果期望前者 不如希望各网站 都别用账号密码登录，用设备指纹登录。

[InkStone]

@zhenjiachen
对比方案可以参考 112 楼的设计。其实就是很简单的 nonce+hash 的嵌套。

其实只要换个角度就好理解了：你把密码第一次做了 hash 之后的结果当明文，然后该咋办还是咋办。

bcrypt 说到底只是一个样板方案，只要能达到效果就行，不是说非得严格死板一条条按它那个来的。

[Huelse]

确实不太好，https 只是保证传输过程安全了，客户端和服务端都不一定安全，像 Chrome 的密码管理器都是直接明文保存本地的。

[raptor]

虚假的安全更不安全。OP 还是多思考一下吧。

[rlds]

其实对于一个站点而言，密码明文传输和加密传输的区别不大，因为这类密码的加密一般是在客户端（浏览器,app ）完成的。得到你的密文和明文都一样能登录。只不过明文还可以被用来去其他站点尝试登录。但是有 2FA 就不一样了，2FA 是动态的，更大程度的保障了账号的安全。但对于论坛这类没什么特别重要的东西，我是觉得没必要开这样的功能。

[GeekGao]

冷知识：世界第一身份云服务商 Okta 也有一种登录模式也是传输明文账号密码
请思考：某些场景下为何要保持明文密码？🤔

[dzdh]

针对附言 2：

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

[davin]

能用个性账号的一概不用邮箱，能用邮箱的一概不用手机，只能用手机的，mmp

另外，第三方调用 Google 登录，目前 Google 已经是在给登录设备发送随机数字，设备上点选对的数字就通过登录了