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

好几位说我举这个例子客户端不安全了任何手段都没意义了，但是请注意，我上面只是举例子、并不是说这个例子代表所有情况。
再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。

好些人举例子 github ，github 对安全的要求级别是低于金融、电商那些 FIN Tech ，所以刚才我看了下 Amazon 的，登陆的密码是很长的 encryptedPwd 字段，淘宝我没试因为之前看过别人帖子说也不是明文

很多人还是没想明白，多加一步非明文成本没增加、几乎可以忽略，为什么不能多加这点？我实在不理解，各位坚持明文的在倔强什么。。。


> 每次看到说要前端加密的, 都很无语, 发这种帖子说明你水平低下

@weijancc 上面这句是这位兄弟的, 你说话是真没礼貌, 那我也不跟你客气了, 送你两句话八个字:
1. 看懂再说
2. 菜就多练

道理已经列举过了
简单粗暴点从实践出发, 我就想咨询下各位坚持明文的兄弟: 为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?

没尝试太多大站, 只列举这么多吧, 哪位坚持明文的来解释解释

补充一点: 标题里我少打了符号, 标题意思不是说 HTTPS 是明文, 而是指: 用了 HTTPS, 在 HTTPS 的信道之上传输的 HTTP 参数里使用明文(这个明文在 client 端和 server 端而言都是明文)

@msg7086 @mightybruce

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

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

即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.

所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.


> 但不是所有业务都需要那么高的安全级别，再直白一点，有成本

@iyaozhen 安全级别的问题确实是关键, 并不是所有站都需要这么高的安全级别. 但成本这个我不太赞同, 因为简单的不使用明文只需要哈希盐一下, 我觉得很多站不用, 是因为不需要那么高的安全级别+历史惯性+认知, 例如帖子中很多坚持明文的人的认知


> 为什么你会这么想？很简单，你的逻辑思维能力不行。

@LandCruiser 说不礼貌的话之前, 建议先看懂别人是什么意思再说

刚开始我没理解为什么那么多人还要坚持明文, 这两天 get 到一些了, 我琢磨可能是因为, 很多人自己这样用了习惯了, 所以这是属于舒适区, 人的天性就是难以从舒适区里出来
外加经济学上的"沉没成本效应", 因为自己学习领会了一些 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 已经是在给登录设备发送随机数字，设备上点选对的数字就通过登录了

[iyaozhen]

楼主你说的没问题，但不是所有业务都需要那么高的安全级别，再直白一点，有成本

“另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失”，我来说说有什么成本：
1. 你密码加密用什么方式，RSA ？还是先 RSA 传递密钥再 AES ？
2. 密钥轮换策略呢？为了安全最后是每个用户密钥不一样，还有保存和轮换的问题
3. 密码要加密，传递的用户敏感信息（比如身份证号）是否要加密呢。你不要说这个不用，按严格的隐私保护策略，也需要，防止中间层泄露
再扯远点按欧盟或者一些其它地方的隐私保护，你很多数据存数据库都是要加密的，但为什么不做，还是成本

https 为什么能铺开，就是因为应用层不需要任何修改，网关加一层 https 就行。再加上浏览器厂商的强制推行，这才普及，不然没人改的。

工作这么多年（ TOP3 大厂），非资金或者涉密相关的业务，就普通 web/app 。安全很多时候都是嘴上说说，而且很多人嘴上都没说对。但近几年为什么安全确实越来越重视了，1 是法律法规的影响（不说欧盟，国内也有，这不信息安全月才过去）。2 是各种平台的严格审核，最常见的就是 Android 日志里面不能打印隐私信息，拒审几次就教做人了 3 是安全事故确实影响大（倒不是说用户信息多少珍贵，是舆情风险）
说的这些并不是说我不赞同做的更安全（反而我是 ToB 的，某些场景为了安全投入了 N 倍的开发成本），但实际情况就是有很多成本和意识问题。

[iyaozhen]

@YangWaleed +1 前端加密方案不拿出来说没有意义

不能高估大家的技术能力，比如短信验证码接口上直接返回的事情都有，前端加密这种更复杂的工程，更容易出篓子。实际就是成本和收益不成正比。

[LandCruiser]

你说的不成立，前后端都是一个公司开发的，加不加密你都防不住它获取你输入的真实密码。因为让你看起来“加密了”很简单，我直接在你输入的每个字符之间随机插入 10 个字符，你看得出吗？后端获取密码后直接隔 10 位字符取值就行了，你忽略了一个重要的点，前后端都是一个公司开发的。
为什么你会这么想？很简单，你的逻辑思维能力不行。

[belowfrog]

@FengMubai #4 你没分清楚，“用户”不想让服务端知道隐私，还是“前端”不想让服务端知道隐私？这里讨论的前端吧，用户能做的就是不要用同一份密码

[iseki]

单从避免用户主口令泄露这件事上来说，要做一个可靠的方案成本比较高，前后端可能会有超过一个 RTT 的挑战响应机制。比如后端存储用用户主口令加密过的私钥，然后在用户代理（浏览器）中完成挑战响应，这样可以保证用户主口令不离开用户代理。
如果前端简单哈希一下，暂且不论能否提高安全性（加盐会很难做，固定的盐没有意义），哈希后的结果会不会缩减值空间，反过来降低安全性，可能也有待评估。

[RainyH2O]

客户端靠密码管理器，服务端靠 WebAuthn 。传输明文肯定是不够那么安全的，不能说某些大站这么做就等于是安全的标准真理。做出不够安全的系统就乖乖立正挨打别嘴硬，不是不能理解因为开发成本等因素不能也不必要做到那么安全，但批评你不够安全的时候心里要有点数。

[lesismal]

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

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

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

[iseki]

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

[lesismal]

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

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

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

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


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

[iseki]

也许可以在前端对口令完成一次困难哈希，但难度和风险在于这个哈希的算法和参数从此固定不能更改，也意味着日后所有的「客户端」都要能自主完成这套逻辑。

[leonshaw]

和数据库不能存明文密码一个道理，不是要防止服务端获取密码，而是防止服务端「记录」密码。如果前端传明文，那密码就有可能躺在某个日志、某次服务 debug 时的抓包文件里等着有心人读取。大厂用明文是因为它相信自己能杜绝上面的情况。草台班子往往只看到了明文传输，没看到后面的安全防护工作，当然也可能根本不在乎。

[lesismal]

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

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

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

[lesismal]

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

[lyxxxh2]

"例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码" ???
"例如有人在你电脑上装了键盘监控或者在旁边装个针孔摄像头"

再加密下文字可以解决些小安全问题。
但是谁说为了解决小安全问题,而要我加密,我敲死他,吃太饱了是吧。

[csrocks]

我有个问题,
现在假设数据库存的密码是 md5(password+salt+password), 如果需要在前端 hash 之后再传给服务端, 那么我的加盐方式是不是也一起暴露了?

[iseki]

@lesismal 这文本复制的可真有意思，也怪我，下次用 Kotlin 风格的方式表达。
这个接口的风格是工程要求，你也可以看一下我在这条文本之后的跟帖，大概有这么个现实问题是不太好解决的，你可以给出你的解决方案讨论一下。

[kiripeng]

https 的情况下，密码 md5 和 sha256 都是为了让项目组人员安心，跟明文其实没啥区别，在前端各种盐肯定会被暴露。我个人认为是图 [安心] ，数据库存密码加 salt 和非对称加密我觉得才是主要的

[lesismal]

@csrocks @iseki @kiripeng

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

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

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

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

[wtfedc]

OP 说半天也说不到点了，逻辑有点无厘头，看的是真急。

前端做处理，想到两种场景，跟 op 描述的东西不沾边：
- lifei6671 这个哥们说的，服务提供方是不可信站点，用明文去撞库。
- 预防中间链路被攻击，比如 浏览器 <-https-> CDN/其它边缘节点 <-http-> ECS 这种，如果 CDN 到 ESC 之间的路由节点被攻击，是能拿到明文，但这个是服务提供方考虑的。对于普通用户来说，用大厂的服务，已经默认它的安全性了，再去考虑怎么预防大厂内部出问题，多少有点没有性价比。

前端代码是完全暴露的，额外做的加密也是完全暴露的，即使用 web assemblely 引入二进制，依然是可以被攻击方调用。想从前端本身去加强安全，没意义。

[lesismal]

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

[lesismal]

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

[iseki]

@lesismal 工程上多一行代码也是有成本的，不能做不划算的事。我可以接受口令在妥善的哈希后传递给后端，但我不能接受把口令 base64 之后传给后端，base64 在这里就是一个收益近乎为 0 的操作（即使它的成本很低），总结下来就是一句话，不做不必要的事。
避免向后端传递原始口令是有必要的（中间设施，日志系统，甚至后端服务本身都可以有缺陷和风险），但必须弄清该怎么做，而不是简单变换一下弄得一眼看不出来就完了。

[lesismal]

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

[openmynet]

https 与密码安全的事情不早就又定论了吗！？@FengMubai 所提出的密码隐私问题更值得讨论。一旦个人信息被获取，特别是那些未经复杂混淆处理的密码，它们可能就像线索一样，轻易揭示其他关键密码。相比之下，经过深度混淆的密码，即便被试用在部分网站，尽管仍存风险，但对个人来说，这种潜在威胁显然要小得多。

[MelodYi]

再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证之类的额外的安全策略？
-------------
这个说法是对的，但不全对。
我觉得因为 https+密文的安全的提升有限，还是会需要二次验证等其他风控的策略来辅助。
所以大家就不想再为这部分加密增加复杂度了。

[LnTrx]

看到现在还是觉得，HTTPS 内密码只能就来解决“有坏人但又不完全坏”的场景，例如：
1. 后端人员出问题原则上什么都可以拿到。但是也许有人看到明文 log 心生歹意，但是密文 log 就不去细想。
2. 中间人出问题原则上什么都可以篡改、窃取，但是也许有中间人只会拿明文 log ，不会分析前端加密、不会篡改前端直接拿到明文。

换言之，这种方法可以增加安全性，但增加的是非常狭窄的场景。同时，给工程增加复杂性、营造虚幻的安全感也可能会降低安全性。因此，不同厂商可能会有不同的取舍。

[aababc]

感觉这个问题讨论不出来个啥结果，既然觉得密码有安全问题，那么就不用密码就好了！把这个安全问题交给别人就不需要自己负责了！

[agag]

@icy37785 感同身受，本来以为开个帖是和大家一起讨论的，结果只看到过强的主观意识，但就第一点成本来说，OP 可能接触的更多是互联网行业，对于很多金融行业、机关单位，这点改动带来的可不是小成本。

[lesismal]

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

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

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

[ywisax]

要看你是什么角色去对待这个业务。
你是安全人员/东厂/网安爱好者，你对业务的要求一定是“更加安全”。
你是业务开发/需求方/老板，你对业务的首要要求一定不是“更加安全”。

网络安全是要靠事故驱动的。既然“使用 HTTPS 用明文传输密码”不是一个明显的安全问题，没出过事，那就没必要投入，你是项目负责人你也会这样选择，没必要的东西为啥要增加成本。

[rabt]

看了这么多类似的帖子和评论，也学到了很多，省流一下：对用户来说，别用相同的密码。

[cp19890714]

这本质上是职责问题.
网站在安全方面的基本职责是, 保证 用户使用网站的链路可触及的范围内, 保证用户信息安全, 包括:
* 传输过程安全
* 运行中安全
* 存储安全

如果用户本地不安全, 使用了代理, 有中间人 等等, 这些是否是网站的安全职责所在? 我认为肯定不是.
客户端 hash 固然可以提升一定的安全性, 但这会导致网站的安全职责无限扩大, 到什么范围才是个头?

不同层级的应用负责本层级的安全就可以了. 职责不应该无限扩大.
界定职责范围, 在各自范围内自治.

[lqbk]

安全要从逆向去看，要从进攻者的方向看。

对于对抗破解攻击有效果的行为，都是安全的行为。

[iyaozhen]

我先说一下讨论的基线，一般流程：
https 明文密码+后端 salt hash 存储

再说楼主的方案：
[因为简单的不使用明文只需要哈希盐一下]

比如中间有泄露的可能，假设是在 CDN
对于我自己的网站，黑客还是可以直接使用前端 hash 的结果重放。策略无用
最大的作用是这个密码不能去其它网站撞库了

但带来一些工程上的复杂性，前端 salt 如何轮换？

当然前端 hash 这个问题也是月经贴了。这个不是重点，我的意思是现有方案已经足够安全了（一开始说的基线），前端 hash 并没有安全太多。

[lesismal]

@iyaozhen #154

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

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

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

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

[lesismal]

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

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

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

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

[IvanLi127]

@Bingchunmoli 能降级攻击了，如果是网站，直接改改网页给用户代理，去明文回来不就完事了？ app 正常开发的话应该不会降级吧。

[Anarchy]

作为被 CSDN 脱库都受害者，还是希望开发者们至少对密码多下点心。然后实际的攻击者也不是挑战密码学，感觉把安全想得太狭隘了。

[viruscamp]

如果你能推进网站前端采用密码哈希方案了，你就不能推进网站后端采用 bcrypt 或更安全的验证算法，推进网站后端 log 脱密记录？后面两件事的优先级怎么都比前端 hash 要高的吧？如果网站后面两件都做了，前端 hash 就没意义。如果网站后面两件都不做，他会听你的意见采用前端加密吗？

关于“密码(口令)明文是隐私, 不应该让服务端知道的隐私”，不可能所有网站都采取前端密码 hash ，只有一视同仁，每个网站都用随机生成长密码，记录的事交给密码管理器(windows 自身，linux 的 kwallet ，keepass)，你记忆的密码只有密码管理器的。

[cybort]

@msg7086 因为用户自己想出来的密码不只用在这一个地方，还可能包含其他信息。如果大家都存明文，那只要一个被攻破了就全漏了。

[cybort]

@790002517zzy 关键不是能不能获取到加密方式，而是不同网站的加密方式不一样，拿到的数据没有重用价值。

[viruscamp]

我见过几种 https 基础上用户侧密码加密的几种方案
1. 前端密码用固定的 hash 算法固定的 salt ，算出哈希后传给后端。如 @cmdOptionKana 所说：那么密码就是这个哈希值啊
2. 前后端协商出一个临时密码（包括前端随机一个给后端，后端随机一个给前端，某种基于时间的算法前后端同时算出），前端加密密码传给后端，后端解密。我的评价是，脱裤子放屁，发明了一个很不安全的 https
3. 更聪明一点，前端有后端给的公钥，时间+密码，加密后给后端，后端解密，验证时间(30 秒内)，得到密码。抓包得到的加密字串每次都不同，而且有效时间很短，如果后端短期内记录使用过的密码，有效期内的重放攻击也可以基本解决。这个思路，必须再往下走，前后端交互公钥，所有传输公钥加密，那么这离真的 https 基本就差安全的公钥验证了。

[Bingchunmoli]

@IvanLi127 代理你 rsa 加密就不会明文，不加密就是明文， 这个场景举个例子就是路由器不信任或者说路由器这种被攻击，设备可信但网络不可信（另外一种可能公共网络）

[IvanLi127]

@Bingchunmoli 你不觉得上下文全拿到就能解密还原么...不然咋交换的 rsa 密钥。

更重要的是，如果是针对特定场景攻击的话，对于网页来说，你以为你你被监听，实际上你根本没有访问目标网站，而是攻击者的站点，加密不加密是不可信的中间设备决定的...这个很明显加密解决不了问题了，人家可以轻而易举地把加密去掉。简陋的形式类似用官方域名的钓鱼网站

[msg7086]

@cybort #160 你说的没错，所以才需要推广密码管理器，一站一码。
前端加密不是解决明文存储密码的方案。毕竟，都为了安全去搞前端加密了，怎么还会去明文存储密码呢……

[msg7086]

针对 append 部分
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴
你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.
所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.

==========

我感觉你说了这么多还是没讲到点子上。我觉得你最好重新整理一下自己的思路，否则就我看评论区的样子大家都在各说各话，讨论不到一块儿去。

就拿我司我们 org 的习惯来说吧。如果你要做一项比较大的功能改动（你说的前端加密就已经是比较大的改动了），一般需要先开一个 wiki page 把改动写在文档里。
文档分几个部分，首先是摘要，说明现状如何，遇到了哪个具体的问题，会造成什么样的后果，产生什么样的经济影响。（比如出了一个 bug 造成 3 个客户的业务离线各 3 小时，这就是经济影响。）然后是你的大体设计，这里一般简单说几句画个流程图什么的就行了。然后是产生的实际影响，比如说原本一个 bug 造成某个操作需要花 3 小时跑完，修复了 bug 只要 1 小时就能跑完，等等。

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

如果这是你自己的个人项目，躺在沙发上看电视无聊了突然一拍脑瓜想到了这个方案，爬起来给自己网站加上，这倒是无可厚非的。但是对于正规的企业级项目来说（不管是 GitHub 也好百度也好还是 Amazon 也好），一个 Jira 的立项是需要 business justification 的。就拿我们组的项目来说，修改一处很小的逻辑，也要经过（ 1 ）事故单或者 Filer 提需求（ 2 ）需求分析并撰写 wiki page （ 3 ） Manager 和 Tech lead 审核批准，如果是跨部门的单子还需要其他部门的底层员工和 Manager 签字（ 4 ）确定上线时间，和 Release Management 沟通（ 5 ）写代码，然后为代码写测试覆盖（ 6 ） Peer review （ 7 ）开服务器然后组内测试（ 8 ） FullTest 自动化测试（ 9 ）质量控制组人工测试（ 10 ）运维组人工测试（ 11 ） Demo tenancy 上线测试（ 12 ）分批灰度上线测试（ 13 ）完整上线，正式结案。

当然，不同公司规模不同，流程也不尽相同，但归根结底不要忘记了，加个功能不是拍个脑瓜公司就批给你那么多人工的，工程师又不是天天闲着没事干，处理更高等级的任务都忙死了，为什么要浪费时间处理一个无所谓有无的东西，除非你能说服你的 Manager ，不做这件事就会造成公司损失，否则没人会鸟你。

个人项目，还是那句话，你想做尽管做就是。但不要随便把手指指向别人的项目。这种行为我们有个很常见的说法，叫外行指导内行。

[msg7086]

其实刚刚又想到个事。
加密通信的时候，加密的算法和代码要不要保密或者混淆？
可能有人会觉得，加密算法当然应该保密，攻击者拿不到加密解密方法，那不就安全了吗。

但……

[holulu]

"为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? "这个感觉是不是在 https 还没普及的年代才这么干的？后来 https 普及了，但这些厂商懒得改，就继续沿用而已。
另外就是 OP 多次提到设备借给别人使用，然后被挂代理或抓包拿到密码的情况。如果都被中间人攻击了，还需要拿到你的密码吗？而且不理解为啥把自己的设备借给别人用，手机和电脑难度不是像身份证和银行卡一样重要的吗？

[bullfrog]

建议 lz 保护自己的指纹，平时都带上手套，这样没有什么额外的成本但是安全强度提高了

[NoKey]

@msg7086 密码攻防这一块，一直以来的一个基本理论就是，算法代码本身起不到保护作用，非对称加密算法都是开源的，保护秘密的本身是密钥，不是算法

[Bingchunmoli]

@IvanLi127 rsa 怎么会交换全部密钥呢，如果交换全部密钥还是非对称加密吗

[IvanLi127]

@Bingchunmoli 抱歉，当对称加密了.... 那就只能针对攻击了。

[plko345]

支持非明文，虽然说不出太多理由，也无法反驳坚持明文的观点，但还是强烈支持

[crystom]

这是微信小程序的推荐设计，是要加一层的： https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/safe-password.html

[8520ccc]

实在想加安全性，那就 使用公钥加密 hash 值+时间戳+随机数 这样即使拿到密文数据 也能防止重放攻击

[kenvix]

首先肯定是不安全的，这我非常赞成。
不过出于实现成本的考虑，我仍然明文传输

[cmdOptionKana]

@Anarchy

> 作为被 CSDN 脱库都受害者，还是希望开发者们至少对密码多下点心

注重密码安全是应该的，比如后端不要储存明文密码就是因为拖库事件而逐渐成为行业标准。

但注重密码安全不等于做无用功搞心理安慰，“前端加密密码”这种行为相当于在机房摆个香炉祈求神佛保佑安全，都是心理安慰，不宜提倡。

[iyaozhen]

@kenvix
@viruscamp

我和两位老哥观点一致，作用肯定是有作用的。但要想大范围推起来，还是很难的，就是有成本（不仅仅是技术方案）。

HTTPS 能推起来我始终觉得浏览器（不记得是不是 chrome ）功劳最大，如果它不提示“不安全的”几个大字，到现在都可能还是 http 为主

[lesismal]

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

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

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

[lesismal]

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

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

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

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

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

[lesismal]

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

[lesismal]

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

[kinkin666]

明文传输密码的页面估计也允许保存密码，而且在密码框里也是明文密码，近源攻击的时候摸到机子上去直接 F12 把 type=password 改成 type=text 就显示出来了

[lesismal]

@qq135449773

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

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

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

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

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

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


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

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

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

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

[lesismal]

@LuckyLauncher

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

都重要

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

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

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

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

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

[livin2]

表面分歧在安全实际在于成本，hash 加个盐确实没啥成本。但是，OP 你也看到了，这沟通协调的成本也是成本。有完善的规约/文档，没有存量的屎山，那当然没问题。而现实往往是扯皮甩锅能少干绝不多干的击鼓传屎。
"脱裤子放屁" ？很多时候其实是在屎山面前对括约肌没有信心。
"数据库不存明文"不也是得靠别人脱裤来教育。

[lesismal]

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

[LuckyLauncher]

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

你不猜你怎么知道哪些厂为啥不加密？这两家都是你主导的还是你认识主导这个需求的人？你不过也只是在按照你的方向猜测罢了

[lesismal]

> 你不猜你怎么知道哪些厂为啥不加密？这两家都是你主导的还是你认识主导这个需求的人？

@LuckyLauncher 我都是在按照逻辑讲安全的, 因为一些人举例子 github 说大厂用明文所以就该用明文所以我举大厂的反例

> 你不过也只是在按照你的方向猜测罢了

我不是靠猜测, 都是按道理按逻辑在讲. 我举例子反驳他们 github 的例子, 虽然我没有说原因, 但我相信不用猜测——因为大厂不用明文的原因就是为了更高的安全强度, 这些不需要认识他们主导这个的人

[DefoliationM]

可有可无把，前端代码都是相当于公开的，加不加密无所谓，倒是二次验证 totp 这些支持一下还是很有用的。借用电脑这种，直接电脑装个键盘记录器更简单，20 年前网吧盗 qq 不就用的这种。可以学那些光刻机的那些控制系统，整个系统全部自己定制，全部加密，销售直接卖整台设备。

[hcbb]

客户端都不安全了，前端加密有什么用，掩耳盗铃。需要另一客户端也进行验证还靠谱些。

[mayli]

一般来说，业界会使用成熟的加密算法和方法来进行验证，也就是不会自行发明轮子。例如安全密码验证会使用类似 bcrypt 和 salt 之类，为了增加安全性引入 2fa 。这种经过验证的安全性技术，用起来一般都不容易出现安全性问题。

对于题主的不信任 https ，进而选择在客户端进行“加密”，在安全性分析逻辑上其实属于“混淆”。因为客户端代码和逻辑都是可以被逆向和检查的，从传统的安全性上来说，基本上属于事倍功半的行为，而且一般情况下，系统的复杂度与漏洞数成正比，可以说系统越复杂存在的漏洞就会越多。引入一个这种技术，大概率是面向 KPI 的 feature ，而不是真的传统意义上的安全。比如说，你如果是客户端实现加密，是否需要引入 salt 或者 key ，那么这个 secret 是否也会通过所谓不安全的 https 通道传输到服务器，这个 secret 服务器需要明文还是可以进一步 hash ，这些都是当造轮子时需要考虑的问题。

当然，另一角度也可以说，我这是特别强力的混淆，就像 D 加密那样，没人可以逆向。这么说也行，不过对于实际场景来说，解决明文用户名密码泄漏的 2fa 技术已经足够流行和有效。即使在 http 情况下，也能一定程度避免 replay attack ，所以大部分公司没有必要投入资源去实现客户端加密。

所以和大部分计算机系统一样，当一个方案已经足够好，另一个方案没有明显优势的情况下，就不会被替换。

另外关于第三方的论点

> 重要的是，各个流程链条上，各自尽量做好自己环节的事情，三方厂商做好自己这一层，出了问题它是要赔钱的，我们不能确保三方一定不出问题，所以自己方负责的链条也做得安全强度更高，有错吗？

“我们不能确保三方一定不出问题”这个思路倒是正确的，但是大部分工业场景是妥协的结果，也就是预算情况下的最廉价解决方案。比如 TCP 本身已经保证不会丢包和乱序，在 tcp 初期，这个 tcp 第三方因为不被信任所以好多程序会自己发明个网络协议。但是 2024 年，不会有程序在 tcp 层上面再去检测乱序或者丢包，大多数情况下，文件传输后，算一下整体的 hash 就够了。妥协的结果就是，大部分的底层结构已经足够可信，对于登陆安全性方面，fidelity 用的明文，chase 用的混淆，我觉得都可以接受。

[lesismal]

> 对于题主的不信任 https

@mayli 我可是完全没说过这话啊兄弟, 你和其他很多楼一样, 几乎完全没 get 到我说的是什么...

[parareptilia]

防撞库?

[viruscamp]

我觉得 OP 有点迫害妄想症了，用户不相信网站，网站前端部门不相信后端，后端部门也怕开发人员假装无心 log 打出来了。

那 OP 也应该怕前端加密的 js 的代码里藏了记录原始密码的后门。

我建议别用担心的网站，非要用的话，一定要一站一码。

OP 信任密码管理器吗？操作系统或浏览器自带的密码管理器呢？再关掉密码同步功能呢？都不信的话，用个小本子记吧。

[jacksparrow414]

看了目前为止所有的回答，我还是同意 @msg7086 说的。首先就讨论问题来说，他没有代入情绪，即使有分歧，他还是在确认分析，然后给出自己的想法。其次，就解决方案来说，我们的工作流程和他的大概类似，一件事在公司角度来看，是需要有效益的。所有的成本都要计算在内，如果效益不明显，还浪费了很多人力资源，公司显然不愿意主动去做。除非这件事影响到它的生存或者重大利益了。个人的话，你想怎么干都行；公司的话，还是有很多因素要考量的

[bullfrog]

指纹本身就是技术问题，可以解锁很多东西，即使现在用不到以后也可能用到，而且指纹无法改，在你摸门把手电梯按钮的时候都是明文传输，最应该做好保护，当然如果你家里有矿不怕偷，那也随意，我也不在乎这些

[msg7086]

@lesismal
> 你有没有想过, 很多黑产搞到东西, 但每年我们看到的新闻有多少? 被你知道的泄漏了的只是冰山一角, 你没看到不代表明文就安全了, 也不代表改造后就没带来更全的安全性.

谁出钱谁说了算。你出钱吗？你不出，所以你说了不算。

你尽管叫破喉咙，但破喉咙是不会来理你的。决定企业做什么的是企业的老总，是 org 的负责人，是 PM ，是 tech lead ，不是你。当然你可以自愿加班去完成我上面说的那些，但这关我什么事呢。你是想说服我无偿加班给公司项目加这个功能吗？我可太谢谢你了。

在资本的社会里谈理想，你的想法是不是有点太甜了。

[msg7086]

你自始至终都没有对 Before 和 After 做过具体的案例分析，帖子里基本就是一些假大空的呐喊，什么坚持明文啊什么舒适区啊什么天性啊。怎么不上点干货呢。

这么高一层楼 200 来个回复，说句实话，非常给你面子了，因为讨论的过程还算礼貌，v 站大多数人也不愿意说脏话。换到激进点的论坛里，就不知道是你保卫家人在先，还是管理员看不下去直接 ban 号在先了。帖子内容太过贫乏，甚至激不起我一点讨论技术的欲望。有句话叫，非蠢即坏。看你讨论过程，好像也不像是坏，那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的，有一种老子说的才是对的，你们不同意那一定是你们都是傻逼。那这就没法聊下去了。

大家的耐心是有限的，有些人「蠢」，是因为缺乏知识，旁人点拨一下，去学习了知识，懂了，就不「蠢」了。有些人坚持自己错误的想法，大家劝了劝，发现没什么用，那只好 block 之，以免浪费自己时间。

看到这种纯粹引战的 append ，我的耐心已经用完了。觉得自己老牛逼了，看别人都觉得傻逼的人，我诚挚建议你，以一种圆润的动作姿态离开这个看法和你不同的人组成的社区。

言尽于此，block 了，请勿再回，我不会收到提醒，也不会再浪费更多的时间在这个帖子里了。

[viruscamp]

我认为的优先级
1. 网站全站 https
2. 网站后端采用 bcrypt 或更安全的验证算法
3. 用户一站一码
4. 网站后端 log 脱密记录
5. 网站 OTP 登录
...
100. 用户自己写个插件，把输入的密码转换后再发送
101. 用户对网站源码进行安全分析
102. 网站前端加密