这是一个创建于 181 天前的主题，其中的信息可能已经有所发展或是发生改变。
在隔壁 #71 #74 回复过了，但估计很难被人看到，所以单开个帖： https://www.v2ex.com/t/1043320
github 的问题也不是没被暴出来过： https://zhuanlan.zhihu.com/p/36603247
单就传输信道而言，https 能解决中间人问题，明文在这个用户前端到厂商之间的 https 信道范围内没问题。 单就 github 而言，因为有二次验证，所以即使拿到密码了换个设备也登陆不上，所以有一定合理性。但 v 站没有二次验证，用明文我个人观点不太赞成
安全不只是传输信道，传输信道中间人之外还有社工、复杂的人生场景，例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码，以后说不定做什么坏事，这就属于传输信道之外的安全场景了。
用了 https 就明文只解决信道安全问题，用明文至少意味着：
- 用户应该尽量管理好自己设备的安全
- 用户到厂商之间的 https 信道之外的处理流程上，厂商应该确保安全，例如上面引用的文章里提到的 github 爆出来的问题
另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失？
- 成本：几乎没有增加额外成本
- 收益：安全强度提高了
- 损失：安全上没损失，但厂商不知道你明文，至于厂商知道你明文有什么好处，自己脑补吧
很多人都是觉得：有人用明文，尤其是有大站例如 github 用明文，所以就是对的，根本没考虑过信道之外的安全，也没有考虑大站是否有额外的安全策略例如二次验证，也没有去统计对比，是不是所有大站都用明文、或者用明文的大站占据绝大多数，也没有去区别不同站的类型和对安全的需求等级，比如是否涉及资金安全的，例如金融类、电商类相关的接口
再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证之类的额外的安全策略？
第 1 条附言 · 181 天前
好几位说我举这个例子客户端不安全了任何手段都没意义了，但是请注意，我上面只是举例子、并不是说这个例子代表所有情况。
再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。
好些人举例子 github ，github 对安全的要求级别是低于金融、电商那些 FIN Tech ，所以刚才我看了下 Amazon 的，登陆的密码是很长的 encryptedPwd 字段，淘宝我没试因为之前看过别人帖子说也不是明文
很多人还是没想明白，多加一步非明文成本没增加、几乎可以忽略，为什么不能多加这点？我实在不理解，各位坚持明文的在倔强什么。。。
> 每次看到说要前端加密的, 都很无语, 发这种帖子说明你水平低下
@weijancc 上面这句是这位兄弟的, 你说话是真没礼貌, 那我也不跟你客气了, 送你两句话八个字:
1. 看懂再说
2. 菜就多练
再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。
好些人举例子 github ，github 对安全的要求级别是低于金融、电商那些 FIN Tech ，所以刚才我看了下 Amazon 的，登陆的密码是很长的 encryptedPwd 字段，淘宝我没试因为之前看过别人帖子说也不是明文
很多人还是没想明白，多加一步非明文成本没增加、几乎可以忽略，为什么不能多加这点？我实在不理解，各位坚持明文的在倔强什么。。。
> 每次看到说要前端加密的, 都很无语, 发这种帖子说明你水平低下
@weijancc 上面这句是这位兄弟的, 你说话是真没礼貌, 那我也不跟你客气了, 送你两句话八个字:
1. 看懂再说
2. 菜就多练
第 2 条附言 · 181 天前
道理已经列举过了
简单粗暴点从实践出发, 我就想咨询下各位坚持明文的兄弟: 为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
没尝试太多大站, 只列举这么多吧, 哪位坚持明文的来解释解释
简单粗暴点从实践出发, 我就想咨询下各位坚持明文的兄弟: 为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
没尝试太多大站, 只列举这么多吧, 哪位坚持明文的来解释解释
第 3 条附言 · 181 天前
补充一点: 标题里我少打了符号, 标题意思不是说 HTTPS 是明文, 而是指: 用了 HTTPS, 在 HTTPS 的信道之上传输的 HTTP 参数里使用明文(这个明文在 client 端和 server 端而言都是明文)
第 4 条附言 · 181 天前
@msg7086 @mightybruce
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴
你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.
所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.
> 但不是所有业务都需要那么高的安全级别，再直白一点，有成本
@iyaozhen 安全级别的问题确实是关键, 并不是所有站都需要这么高的安全级别. 但成本这个我不太赞同, 因为简单的不使用明文只需要哈希盐一下, 我觉得很多站不用, 是因为不需要那么高的安全级别+历史惯性+认知, 例如帖子中很多坚持明文的人的认知
> 为什么你会这么想？很简单，你的逻辑思维能力不行。
@LandCruiser 说不礼貌的话之前, 建议先看懂别人是什么意思再说
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴
你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.
所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.
> 但不是所有业务都需要那么高的安全级别，再直白一点，有成本
@iyaozhen 安全级别的问题确实是关键, 并不是所有站都需要这么高的安全级别. 但成本这个我不太赞同, 因为简单的不使用明文只需要哈希盐一下, 我觉得很多站不用, 是因为不需要那么高的安全级别+历史惯性+认知, 例如帖子中很多坚持明文的人的认知
> 为什么你会这么想？很简单，你的逻辑思维能力不行。
@LandCruiser 说不礼貌的话之前, 建议先看懂别人是什么意思再说
第 5 条附言 · 179 天前
刚开始我没理解为什么那么多人还要坚持明文, 这两天 get 到一些了, 我琢磨可能是因为, 很多人自己这样用了习惯了, 所以这是属于舒适区, 人的天性就是难以从舒适区里出来
外加经济学上的"沉没成本效应", 因为自己学习领会了一些 https 和加密等领域相关的知识, 就使用这些知识点头疼分析头脚疼分析脚, 只管自己处理的环节, 从而忽略了整体流程上包括社工之类的的完整安全
外加经济学上的"沉没成本效应", 因为自己学习领会了一些 https 和加密等领域相关的知识, 就使用这些知识点头疼分析头脚疼分析脚, 只管自己处理的环节, 从而忽略了整体流程上包括社工之类的的完整安全
228 条回复 • 2024-10-25 23:23:35 +08:00
 |
1
body007 181 天前  1
v 站也有 2FA ，这是二次验证吧。
|
 |
2
lesismal OP > v 站也有 2FA ，这是二次验证吧。
@body007 #1 在哪里，我没发现。另外，即使有、也应该是强制用二次验证才算是安全上起到作用，不启用的话就仍然强度偏低。但是 v 站或者其他论坛这种产品类型的信息不涉及资产之类的，所以还好，用户多站共用相同密码问题更大。 github 我不知道现在是不是必须使用二次验证了，好像也是最近哪一年才开始推二次验证的吧 |
 |
4
FengMubai 181 天前 12
我放弃说服哈希更安全了. 换个思路, 我想说, 密码(口令)明文是隐私, 不应该让服务端知道的隐私
|
 |
6
hefish 181 天前 2
现成的 DH 交换算法，面试前大家都复习过吧。 实际应用的时候，就偷懒了。。。共享密钥必须是算出来的才算安全，直接传输的，不都得降一级嘛。。。
|
 |
7
cndenis 181 天前 1
安全有一个原则叫纵深防御, 就是当一个防护被突破后, 有另一层防护, 会更安全.
就好比说数据库已经有密码保护了, 为啥不能往数据库里存用户口令明文呢? 同意#5 的看法, 口令 Hash 可以避免受到中间人攻击时, 口令明文被用于在别的网站上做碰撞 |
 |
8
ZE3kr 181 天前 1
> 密码(口令)明文是隐私, 不应该让服务端知道的隐私
同理，私聊的消息是隐私，因此不应该被微信服务器知道 |
 |
9
cmdOptionKana 181 天前 17
只能明文传密码吧？
你的建议是什么？哈希？哈希后传给后端，那么密码就是这个哈希值啊，想做坏事的人拿到这个哈希值可以直接走 api 发给后端，这与明文有啥区别？ |
 |
10
Al0rid4l 181 天前 2
这主要取决于你要防范的对象是谁, 防的就是用户, 那就加密
这么多安全策略, 但是每个都有针对的对象和场景 |
|
11
cmdOptionKana 181 天前 1
另外，对于注重安全的用户来说，只能默认厂家知道明文密码！
对于注重安全的用户来说，每个网站的密码都是不一样的，都是随机生成的，根本不怕厂家知道明文密码。 而对于“不”注重安全的用户来说，你说的这些又有什么意义呢？人家根本不 care 。 |
 |
12
Wy4q3489O1z996QO 181 天前 1
单纯的认为即使有 https 多加一次密又不费事，为什么不把明文加密一下呢
|
|
13
ZE3kr 181 天前 1
首先用了 HTTPS 就不是明文传输密码了。标题本身就是伪命题
其次 1. HTTPS+密码 不安全 2. HTTPS+前端加密的密码 跟 1 一样不安全 3. HTTPS+密码+TOTP 跟 1 和 2 比更安全点 4. HTTPS+Passkey/Biometric 最安全 老网站用 1 是历史遗留问题，1 升级到 2 必然是有成本的，不如直接升级到 3 和 4 。 |
 |
14
Curtion 181 天前
农业银行对接支付的接口也是明文的，只是会有证书验签来保证安全。 只能说加密传输有好处，但是没有那么大，还会增加额外开发成本，如果真的有安全上要求也可以用其它方案来解决，例如 2FA 什么的。
|
 |
15
wolfie 181 天前
加风控呗，新设备登录要求 手机或邮箱验证码，再上一层要求密保问题。
默认拿到手机邮箱的就是本人。 |
 |
16
Jirajine 181 天前 3
你应该把标题改成“服务端能够得知密码原文”。
使用了 https ，其实就已经不是明文而是是加密传输了，在这之上再进行额外多少层的对称还是非对称加密，只要服务端有能力解密得知密码原文，那就都是一回事。 前端进行 hash 的目的只有一个：让后端对密码原文保持 zero knowledge ，其他的安全策略于此是正交的。 |
 |
17
LnTrx 181 天前
个人看下来：
对于用户侧，如果恶意软件/人士已经掌握足够权限，那再 HTTPS 内再加密也没意义。关键是要找到一种场景，HTTPS 内再加密能防住、HTTPS 防不住，且这种场景有考虑的价值。我暂时没还想到。 对于服务侧，经手数据的很多环节都是能看到 HTTPS 内明文的。最典型的就是内容分发，通常 CDN 的本质就是可信中间人。如果数据流转的环节需要再加强防御，那 HTTPS 内再加密还有点意义，据要结合具体场景分析。就拿 CDN 举例，如果 CDN 是坏人，只加密密码，用户隐私、Token 等信息都是明文，那一样可以窃取信息、拿下账户、伪造信息，那加密的意义也就不是很明显。 |
 |
18
mightybruce 181 天前
|
 |
19
0o0O0o0O0o 181 天前 via iPhone
> 例如有人借用你电脑的时候给你设置了个代理或者装了马
威胁如果来自客户端，那我觉得目前提到的所有措施都没办法保证安全，我建议讨论的时候默认客户端是安全的 至于常见争辩的密码加密传输还是明文传输还是前端传个哈希。。。或许可以搜索关键词 PAKE ZKPP |
 |
20
night98 181 天前 1
要讨论的地方就三个点
1.客户端安全 就你举的例子，我直接监听输入不就得了，你就是在 html 页面写出花来我监听键盘输入就搞定了，证书之类的纯属多余。 2.传输层安全 除非你使用的是非正式的证书或 CA 机构不可信导致传输过程被破解，这个有可能，但概率极小，而且一般来说价值不匹配 3.服务端安全 现在基本上都标配 Bcrypt 了吧，很少有直接明文存密码的。如果非要说网关层有泄露的风险，那我只能说你别扯了，有这功夫我插入个 js 脚本到返回的 html 页面中都比你入侵网关去查某一个接口的请求响应拿到的东西更多。 你要真保证绝对安全， 就用硬件来保证，至少比纯密码方案靠谱几倍，直接分发硬件加密码的方式，每次登录硬件生成随机密码来登录，比你折腾那玩意靠谱多了。 |
 |
21
iX8NEGGn 181 天前
这根本就是俩回事。一个是：服务端是否应该保存明文密码；另一个是：是否在 https 下还要明文传输数据。请不要混淆。
|
 |
22
icy37785 181 天前 via iPhone
每次看到这种日经贴就难受，每个发这种日经贴的人都有一种错误的认知，就是认为前段加密或者哈希之后会更安全，至少也和明文同样安全。
但是却从来没考虑过，前端加密也好哈希也好，是有可能更不安全的，而连这种可能性都考虑不到的开发者，可以说会把这种可能性放大到无限大。 例如发这类日经贴的里几乎有九成考虑的是把密码 md5 之后发往后端，把不定长度的字符串弄成定长且仅包含字母和数字还不用考虑大小写的字符串，这不是帮穷举的哥们省事么。 看这类帖子越多，越觉得密码学第一章写得有道理。 |
 |
23
jianchang512 181 天前 1
前端加密会 hash 后肯定比不这样做更安全一点的
1. 可防止 https 信道不安全或被破解的问题 2. 可防止后端可能直接将相关信息输出到日志而暴露的问题 3. 可防止后端万一不做处理直接明文保存 当然作用可能微乎其微，大约类似心理安慰吧，何况有时后端也需要知道明文密码，比如后端也需要验证密码强度时 |
 |
24
tangmanger 181 天前
https 真的能解决中间人问题吗- - 再者 来自客户端的威胁几乎是不可避免呢 加密只是增加破解难度而已
|
 |
25
tool2dx 181 天前
|
 |
26
maggch97 181 天前 5
你跟 V2EX 上的大部分人讨论安全：大部分人会告诉你，你这个不是绝对安全，所以我用更不安全的方法也没什么问题。
甚至嘲讽你一句：做不到绝对安全还敢说安全？ |
 |
28
weijancc 181 天前 2
每次看到说要前端加密的, 都很无语, 发这种帖子说明你水平低下, 你电脑都能给别人装恶意软件了, 加不加密还有什么区别? 如果开发者知道加密的概念了, 那肯定不会在数据库保存明文密码.
上 https 对于安全的保障已经足矣, 你担心厂商偷你的密码, 那这已经是另外一个问题了. |
|
29
LnTrx 181 天前
@maggch97 关键在于要说明对安全的提升有多大。如果只有十分细微的提升，虽然也是好事，但是这样场景数量太庞大，会给工程带来不必要的复杂度。而增加的复杂度又会反过来增加风险。
|
 |
30
kyuuseiryuu 181 天前 via iPhone 18
你都已经假定后端是不安全的了，前端 HTML 不也是做后端的同一个公司的人做的吗，它怎么就更安全了呢？更何况前端代码是任何一个人都能拿到的。
对于社工来说，只要能拿到能登陆的那一串字符串就够了，他根本不在意你那串字符串背后的含义。前端加密唯一的好处就是可以给模拟请求增加难度仅此而已。 明文传输给后端不代表数据库里保存的就是明文呀。 通过配置 salt ，入库的时候混淆哈希完全可以防止被脱裤撞库的。 利用中间件也可以防止敏感信息被记录在日志里，这点就要靠开发者或者公司的规范来保证了。 前端加密方案面对的攻击者是用户本身，他攻击的目标是你网站的业务。 敌人都没有分清楚是谁一顿花里胡哨输出有什么用？ |
|
31
kyuuseiryuu 181 天前 via iPhone
二次验证要解决的问题是“确认本人授权”。
如何保证就涉及到两个核心点 1. 动态验证 2. 仅本人可知 仅本人可知这一点需要验证设备仅被本人拥有。 动态验证需要设备产生的验证信息与服务端同步。 OTP 方案就是服务端和客户端使用相同的随机数种子，生成两端同步的验证码。 再就是公私钥对，自己保存私钥，公钥告诉服务端，服务端生成随机数给客户端，客户端加密后服务端用公钥解密。 以此来证明此时登陆的用户是拥有验证设备的“本人”在授权登录。 |
 |
32
pandaidea 181 天前 via iPhone
如无必要勿增实体
|
 |
33
fpk5 181 天前
> 例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码
假设客户端是不安全的那你任何的手段都没有用 |
 |
34
IvanLi127 181 天前
不相信服务提供商，请不要随意使用...没有信任居然提供自己的密码给他，还期望对方帮你离线加密，很离谱的行为。用户的使用环境不安全的情况下，就不应该用静态密码登录，你说的问题只是用户这边的问题，应该由用户自行解决。
而且你说的和密码都没啥关系，所有传输的数据你也应该要求二次加密，不然不是在裸奔么？这时候就不能 hash 了，得能互相解密，这样交换的密钥又是一个风险，然后咋办？再套加密？ |
 |
35
agagega 181 天前
二次验证防的是密码意外泄露，一般是指撞库这样的情况。TOTP/HOTP 协议从设计上避免了被撞库，OTP 密钥泄露的机会也非常小。
所以不发送明文密码只有一个正面意义，即避免服务端日志不小心泄露明文密码。但问题是服务端处理的敏感信息很可能不只用户密码一项，避免日志泄露密码应该从整个日志体系入手，而不是打补丁一样给密码做个散列就好。还有一点的话，就是散列后密码长度会变得一致，这样再做加密可以避免旁路攻击，不过服务器都能被人这么搞了，那整个网站也早就没有安全性可言了。 说这样可以让厂商不知道明文——整个网站的前后端源码都是厂商的，如果你不信任这个网站，那一开始就不应该去注册。 |
 |
37
NoOneNoBody 181 天前 1
这样做确实有个好处，就是即使服务器被爆了，用户真实密码也不会泄漏，只会泄漏一个“某种算法得出的伪密码”，爆指的是木马、submit data log 泄漏之类，不是数据库被爆（数据库存真实密码那就没什么好说的了）
就是类似 OP 说的第三点好处 厂商嘛，一个用户如何创建密码，也是这个用户 profile 特点之一，取决于厂商的道德观想不想知道这个 profile 特点了，咳咳 如果要防奸商，请使用随机密码，一站一密 说一下 2FA 的思想，2FA 基本上是用于“免频繁登录”的场景的，就是 cookies 驻留，对当前设备“简单信任”，2FA 就是利用另外的设备加强当前“信任设备”仍然在用户本人控制下操作。如果网站不采用 cookies 驻留，同时只有单设备登录，短时需重新登录的话，是没必要 2FA 的，以前很多，但现代极少再用这种策略了，因为用户体验很差，被时代抛弃了（例如之前某电商时不时就要重新登录一次） 2FA 并非加强了密码安全，而是加强操作安全（鉴别为本人），这里默认用户自己已经做了相应的安全措施，如果用户的账密和 2FA 设备是随便乱放、谁都能用的话，那 hash 万次也没用 其实按 OP 思想，最安全是动态密码，每次输入都不同（随时间变化），但服务端总能依据某个算法得出唯一结果作为鉴别，类似 TOTP ，但 TOTP 只有 6~8 位数字是不足够的 |
|
38
NoOneNoBody 181 天前
对于附言：
再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。 =========== 如果登录后，就基本不会存明文密码 对于上述行为，应该养成习惯，关闭 tab 甚至浏览器，再给别人用，ctrl-w 很快的 其实说到底就是对这个“别人”的信任度如何，不关就是很信任了 你应该从来没见过“老公把手机给老婆用时顺手关微信（也包括角色互换，无性别歧视）”这种情况吧？ |
|
39
lesismal OP @cmdOptionKana #5
> 想做坏事的人拿到这个哈希值可以直接走 api 发给后端，这与明文有啥区别？ @cmdOptionKana 是有区别的.明文比 hash 具有更多的被窥探可能性，所以说的根本不是后续接口持有你的明文或者 hash 的问题。 至于拿到这个哈希值可以直接走 api 就更不太符合实际了，实际工程中多数不是每次带上密码明文或者 hash 去做校验，例如 web 前端，登陆认证通过后利用 server 返回的 token 、然后 cookie http only ，这种 token 具有时效性、或者再次登陆时旧的 token 失效。 |
|
40
lesismal OP > 而对于“不”注重安全的用户来说，你说的这些又有什么意义呢？人家根本不 care 。
@cmdOptionKana #11 在普通领域, 五十步笑百步确实没什么意义. 但工程密码安全这个领域一百步就是比五十步要强的, 建议各位看下 #7 @cndenis 说的纵深防御原则, 刚好 CF 上也有介绍, 这里面有 "加密" 的一段: https://www.cloudflare.com/zh-cn/learning/security/glossary/what-is-defense-in-depth/ |
|
41
lesismal OP @ZE3kr
> 首先用了 HTTPS 就不是明文传输密码了。标题本身就是伪命题 兄弟你应该是没有仔细阅读我帖子的内容, 请先读完再说这观点 > 老网站用 1 是历史遗留问题，1 升级到 2 必然是有成本的，不如直接升级到 3 和 4 。 其实成本不高, 主要成本应该是两方面, 一是客户端方面的, 比如原生客户端升级空档期, 而是服务端方面的, 比如用户量巨大不能短时间内全部更新成 hash 盐, 需要停服维护或者新增表项. 服务端的代码修改相对简单, 例如明文和 hash 盐都判断, 两个失败才算失败, 然后更新数据也可以跑任务分批完成所以不影响性能和业务. |
|
42
lesismal OP > 但是却从来没考虑过，前端加密也好哈希也好，是有可能更不安全的
@icy37785 因为是跟明文做对比, 所以我认为你这个观点是指 前端加密哈希后可能比明文更不安全? 请教, 什么情况下会比明文更不安全? 因为我暂时想不到例子 |
 |
44
YangWaleed 181 天前 2
两篇帖子都看了，但感觉缺少一些信息导致感觉两边的讨论不太有效果。
我想知道 “前端加密或者哈希” 的完整方案是什么。前端进行密码处理后，后端服务怎么使用这个处理后的字符串，比如怎么验证正确和怎么存储到数据库。 在我看来，只有明确了完整的方案，才能和 “明文传输” 的方案进行比较。 |
 |
45
lysShub 181 天前
@cmdOptionKana 不存明文密码，即使数据库泄露也不能用于社工库，那些社工库就来自存明文被爆的数据库
|
 |
46
msg7086 181 天前 1
> 很多人还是没想明白，多加一步非明文成本没增加、几乎可以忽略，为什么不能多加这点
1.为什么成本没增加。 2.增加到什么程度才够？ 就比如你说的多加一步加密没有成本，那为什么只加一步加密，为什么不加密两次，加密三次？为什么没有成本的加密只做一次。 如果加密多次也没问题，那么加密五轮就够了吗，还是五十轮呢，或者五百轮？ 上面其实已经有人说了，用户侧加密其实并没有很大的意义，无非是用 5%的成本上升换取 5%的安全性上升罢了。你的帖子的问题就在于你缩小了增加的成本，放大了安全收益，以为这是一个用少量成本就能换取不少安全性的操作。但这种操作在真正学过安全的人眼里根本就不值一提。真正需要偷你鉴权信息的人，不会因为你加了一轮加密以后就偷不了了，而只是让他们多花半个小时把处理加密的行为加到他们的攻击代码里而已。在你为加密了密码传输沾沾自喜的时候，攻击者早就把代码改好了。 > 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆? 因为这才是正确的路线。放弃密码，不要用 what you know 而用 what you have 。 实际上我司（全国排名前五的软件公司）马上就要实施 passwordless 登录了，以后在公司登录账号只需要公司邮箱+手机 App 证书鉴权，不再需要记复杂的密码了。手机 App 则是指纹保护，每次鉴权时按一下指纹即可。 也就是说，邮箱+手机+我的手指，构成了鉴权。 |
|
47
msg7086 181 天前 1
我看了看你引用的原贴，似乎是浏览器插件读取了密码。这其实就是一个很典型的明文密码加密无效的案例。盗取密码的攻击者直接把你输入到文本框里的密码读出来盗走就行了，总不能特地等到你前端加密完了再傻傻地去读加密后的密码串吧。
这种你要防的话就要回到 ActiveX 控件密码输入盘的年代了，安全控件读不到文本框的内容，输出直接就是加密的，这才有意义。 |
|
48
ZE3kr 181 天前 via iPhone
@lesismal HTTPS 就不是“明文传输”了。我本来就是读过全文才发的。标题是错误的
你这里列举的成本就已经比 TOTP 高了，何况 TOTP 带来的安全性提升是更大的。何况 TOTP 现有的论证和组件是更完善的。以及任何安全上的改动必须要有论证，衡量安全性是有标准的，是客观的一件事，不是简单的“觉得”，可以看下现有的安全模型相关的论文的格式，所以大厂肯定更倾向于 TOTP 的方案 |
|
49
lesismal OP @ZE3kr #48 标题确实, 我在 append 里有解释了. 因为引用的隔壁帖子, 都是关于 https 载体之上的, 这个帖子起标题时没注意标点符号导致了你的误解, 但是内容上, 并不是在说 https 本身是明文, 我本身也强调了 https 解决中间人
> 你这里列举的成本就已经比 TOTP 高了 你前面帖子里说的是老网站用 1 的问题, 所以我只解释解决 1 中用明文的问题的成本, TOTP 这些都是属于密钥本身格式之外的, 不管密钥用明文还是哈希盐, TOTP 之类的这些都可以加, 所以这个成本不应该用来对比密钥格式本身的成本. |
|
50
lesismal OP @msg7086
> 1.为什么成本没增加。 一个哈希盐算法, 设计初期就用上的话也不涉及日后把明文升级哈希盐水, 所以就是初期前端的一层包装, 这个成本你给我说有很大, 那我只能表示佩服了 > 2.增加到什么程度才够？ > 就比如你说的多加一步加密没有成本，那为什么只加一步加密，为什么不加密两次，加密三次？为什么没有成本的加密只做一次。 > 如果加密多次也没问题，那么加密五轮就够了吗，还是五十轮呢，或者五百轮？ 清醒点, 这里说的是流程上的明文 vs 哈希盐, 你用什么哈希盐算法是你自己的事情, 里面加密多少次是你自己的事情, 但是对于明文->哈希盐的流程只是一个步骤 你说这个一轮流程加密多少次, 就是硬杠了 |
|
51
lesismal OP > 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
> 因为这才是正确的路线。放弃密码，不要用 what you know 而用 what you have 。 @msg7086 这个正确路线有前提, 要有 app 已经设备认证过然后能扫码. 否则 SMS OTP 或者加上两步验证之类的才安全, 事实上很多大站也确实加了两步验证, 但他们照样也不使用明文, 比如淘宝. 所以我也请各位再看一下我 append 里面的, 为什么很多大站们不用明文. 不要用 github 用明文来反驳了, github 非金融类的安全级别要求算是偏低的了而且因为这明文被爆料过的 |
|
52
lesismal OP |
|
53
lesismal OP > 你前面帖子里说的是老网站用 1 的问题, 所以我只解释解决 1 中用明文的问题的成本, TOTP 这些都是属于密钥本身格式之外的, 不管密钥用明文还是哈希盐, TOTP 之类的这些都可以加, 所以这个成本不应该用来对比密钥格式本身的成本.
@ZE3kr 我不确定是否有误解你 #13 的 1, 因为你说的是密码, 没说是明文密码, 我快速扫内容以为是按照主题在聊密码用明文相关的. 但是你的 2 中有说 HTTPS+前端加密的 跟 1 一样不安全, 所以 1 中应该就是指明文密码, 否则 1 和 2 就一样了, 我有点迷惑. 另外, 这里 2 中通常不是加密, 密码不会太长当然加密算法也能用, 但通常是 hash 指纹这些 |
|
54
msg7086 181 天前 1
|
|
55
msg7086 181 天前 1
其实这帖子我看得很懵，不知道你这个操作到底是要达成一个什么样的效果。
现在我们假设用户的密码是 "3m&y5oDChc"，然后你用 JavaScript 做了一次运算，比如说 md5(password+SALT)，得到 "123456abcdef" 这个 md5 。 你的目标是保护 "3m&y5oDChc" 不被人偷看去，是这个意思吗？ |
|
56
msg7086 181 天前 1
看了你贴的知乎讲 github 和百度的那个帖子。但是有趣的地方就在于，百度的登录请求的那张图里，其实并没有做过 MITM 中间人防护。也就是说，虽然客户端找服务器拿了公钥，加密了密码然后再发回，但其实客户端并不知道拿到的这个公钥是真的由百度发出。HTTPS 证书世界里，要伪造可信证书是很难的，要是哪个厂敢生成他无权生成的可信证书，没几天他的 CA 就要被全球吊销了。但帖子里讲的这种非对称加密就没有这种认证机制。如果有人有心去主动攻击百度的登录服务，这种额外的加密是不堪一击的，攻击者只要自己生成秘钥对替换掉百度的公钥，然后从用户侧拿到数据解密即可完成密码破解。
|
 |
57
ShuWei 181 天前
哎，既然都已经默认用户端不安全了，那哈希也是没意义的啊，上客户端吧，客户端上个驱动，禁止一切可能不安全的行为。至于不能让服务端知道用户的密码，这不更扯淡么，服务端知道与否有什么区别呢，不应该是服务端要注意处理方式么，比如不要明文存储在任何可能被攻击的地方，比如数据库、日志，用完立马清除掉
|
 |
58
Leon6868 181 天前
思考一个问题：假定服务器安全，攻击者是否能完全复制受害者的网络特征并给服务器发包？如果攻击者能做到，那服务器如何判别请求来自攻击者还是受害者呢？
很明显，如果你假定受害者全部的网络行为可以被任意截获或者监听，那么信任链根本无法建立，任意加密、验证手段在中间人面前都是纸老虎。 |
 |
59
saranz 181 天前
不管怎么说，我相信的只有通知和记录。
通过通知功能实现对用户的提醒，通过记录功能使用用户知道那些行为为非已操作。 在服务端，私有的加解密方式也很是一种对不确定的密码安全的防护。 |
|
60
mightybruce 181 天前 1
首先，你说的密码是身份认证和资源授权相关，不是加密
身份认证体系有哪些，我这里列举一下 那个知乎链接中对中间人攻击其实一点都不懂， 不了解 TLS 如何工作， 干的事情也是脱裤子放屁 我要再次强调一下任何加密没有安全认证和解决身份和信任问题都是可笑的。 |
|
61
mightybruce 181 天前
身份认证体系
1 、基于密码的认证 也称为基于知识的身份验证，基于密码的身份验证依赖于用户名和密码或 PIN 。密码是最常见的身份验证方法，任何登录过计算机的人都知道如何使用密码。 2 、双因素/多因素身份验证 双重身份验证(2FA)要求用户提供除密码之外的至少一个附加身份验证因素。MFA 需要两个或多个因素。其他因素可以是本文提及的其他身份验证类型或通过文本或电子邮件发送给用户的一次性密码。“多因素”的涵义还包括带外身份验证，其中涉及第二个因素与原始设备位于不同的通道上，以减轻中间人攻击。这种身份验证类型增强了帐户的安全性，因为攻击者需要的不仅仅是访问凭据。 3 、生物特征认证 生物识别技术使用用户自身生物特征进行验证，较少依赖容易被盗的秘密（例如密码口令）来验证用户是否确实拥有帐户。生物识别身份也是唯一的，这使得破解帐户变得更加困难。 4 、单点登录 单点登录(SSO)使员工能够使用一组凭据访问多个应用程序或网站。用户拥有身份提供者(IdP)的帐户，该身份提供者是应用程序（服务提供者）的可信来源。服务提供商不保存密码。IdP 通过用户通过它验证的 cookie 或令牌告诉站点或应用程序。 5.基于令牌的认证 令牌身份验证使用户能够使用物理设备（例如智能手机、安全密钥或智能卡）登录帐户。它可以用作 MFA 的一部分或提供无密码体验。使用基于令牌的身份验证，用户在预定的时间段内验证一次凭据，以减少持续登录。 6. 基于证书的认证 证书身份验证使用证书颁发机构颁发的数字证书和公钥加密来验证用户身份。证书存储身份信息和公钥，而用户拥有虚拟存储的私钥。 在一些登录系统需要提供提供预先协商好生成的 x.509 证书就是 流行的身份验证方法协议 Kerberos OpenID LDAP |
|
62
mightybruce 181 天前 1
历史上这种自作聪明在安全体系里面加这些还有自我设计安全协议的，都是非常非常可笑的。
密码学和网络安全协议设计是非常非常严谨的学科， 协议每一步都需要经得住逻辑验证，甚至有了专门的形式化验证工具比如 BAN logic 。在下面链接里介绍一下长达几十年没有发现逻辑问题的协议 Needham-Schroeder 协议和后续修复，因为这个分析实在太长了，很多人也不会看 https://codelife.me/blog/2013/06/13/needham-schroeder-protocol/ 建议详细读一下这本不错的安全著作，不要自作聪明，画蛇添足。 Protocols for Authentication and Key Establishment Book by Anish Mathuria and Colin Boyd |
|
63
mightybruce 181 天前
在安全信道中有没有再次加密的必要，除非是要求极致安全，不在乎通信效率的传输比如军事上，其建议的是端到端加密，
也是在安全信道中在开始连接中再次建立起双方的安全信任凭证。这个一些邮件和聊天中都需要手动开启。 中间人攻击对基于 PKI 体系的 TLS 是无效的 那么更复杂和安全的加密认证体系由于计算和实现比如基于身份加密（ IBE) 的方案，使用的是双线性映射（ bilinear pairing) 学术界搞了十几年，工业界落地的都没几个。 最近 10 年搞的格密码，基于格的 Identity-based Encryption （身份加密）倒是有可能落地。 |
 |
64
ShinichiYao 181 天前
https 下明文传输不要紧，重点是不要明文储存(包括日志里)
|
|
65
kyuuseiryuu 181 天前 via iPhone
针对第二条附言，因为他们增加用户绕过他们的客户端的难度是为了防止自己的业务不被恶意利用，。
|
 |
66
macaodoll 181 天前 via Android
非明文传输是为了反爬虫。
|
 |
67
Rehtt 181 天前 via Android
我认为 https+url 密码明文不安全的一个地方是日志记录，比如 nginx 会将访问的 url 写入日志里，如果密码在 query 里那会被写入日志
|
 |
68
790002517zzy 181 天前 via Android
画蛇添足...逻辑都没通，前端永远是公开的代码，再怎么处理别人也能获取到加密方式
|
 |
69
guo4224 181 天前 via iPhone
好重的戾气
|
 |
70
killerv 181 天前
- 安全是分级的，更高的安全性当然会带来更安全的保障，但不是没有代价的
- https 明文传输一般没什么问题，加密传输一般是为了防止内部泄露（服务端记录登录日志、用户网络甚至终端被入侵），这是更高级别的 ---------- 别说 https 下数据加密传输了，国内大厂的全站 https 当年都落后很多…… |
 |
71
Jack927 181 天前
曾经我也认为，上了 https ，就没必要在数据上在加密。
但是现在，我认为，有需要的情况下，得加，而且不局限于密码，任何传输的敏感数据都可以且有必要加 |
 |
72
solos 181 天前 1
可能楼主需要的是密码管理器 你用随机密码就好了 随机密码相当于加密了🐶
|
 |
73
zhenjiachen 181 天前 via iPhone
小公司前端加密确实不需要，他们这些大厂加密是因为可以防止大量爬虫和撞库，他们有技术和能力对抗前端代码的反编译，小公司没这个能力，简单的写个 aes 加密直接就反编译出来了，还不如直接使用明文传输，密码保存在数据库使用 bcrypt 算法来做 hash ，这种算法一定程度上防止了被脱裤爆破出用户密码。
|
 |
74
nothingistrue 181 天前
楼主就是典型的这类人：要求 Windows 密码 20 位+有特殊字符+一个月一换+一年内不能重复，然后导致密码被直接贴到了显示器上。
|
 |
75
LuckyLauncher 181 天前
"再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。"
- 我都用你电脑了，我直接通过控制台获取密码输入框控件的值不好吗？用户输入的总是明文的了吧？ “简单粗暴点从实践出发, 我就想咨询下各位坚持明文的兄弟: 为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?” - 电商领域有没有可能考虑的不是安全性而是反爬机制，你看看他们的风控就知道了，以前淘宝的风控被诟病成人类都无法使用。当然这只是我的猜测，至于厂商为什么选择加密只有他们做加密的人知道了，可能亚马逊和淘宝选择加密的理由还不一样。 |
 |
76
cheng6563 181 天前
HTTPS 是砌一堵高墙，不攻破 TLS 就翻不过去。自己再套一层加密因为没法处理根证书信任之类的问题，相当于往路上丢快砖把人绊倒。你说有没有用那肯定比没有好，但你说有多少用吗抬个膝盖就能跨过去
|
 |
77
Bingchunmoli 181 天前 via Android
没有人考虑过因为大部分网站没有 hsts 导致降级攻击吗
|
 |
78
slack 181 天前 via Android
楼主你最好搞清楚你要防的是什么人，了解一下什么是威胁模型，你这样做无异于画蛇添足。
|
 |
79
Felldeadbird 181 天前 1
讨论安全前，建议加一个前置条件：公司规模。
人少的企业，没专业的运维，专业的安全团队，别折腾了，搞这么复杂推屎山。 特别是没有安全团队的公司，你认为的方法在安全人员眼里就是玩泥巴，一捏就散了。不然为什么搞安全的人工资这么高。 |
 |
80
flyqie 181 天前 via Android
思来想去。
貌似用法也就是在 server 和传输中看不到原始密码了。 剩下好像没什么作用? |
 |
81
duron600 181 天前 1
哦。
|
 |
83
InkStone 181 天前
|
 |
84
abcde123456789 181 天前 1
>再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证之类的额外的安全策略？
不是很理解，你的意思是 https+密文就安全了，就不需要有二次验证之类的额外的安全策略？ |
 |
86
cslive 181 天前
前端加密脱裤子放屁
|
 |
87
yuyuf 181 天前
密码 Hash 后再传输跟明文有什么区别？这种情况，你的密码就是 hash 后的结果。
要说真不要明文传输，那方案就是客户端\前端加密，服务端解密。这个 https 已经实现。 |
 |
88
dzdh 181 天前
google / facebook / payoneer(即便是支付密码) / stripe / paypal / BankOfAmerica(即便是支付密码) / outlook / nasa / nsa
以上都是 https + 明文，不觉得有任何问题。 说本地木马：跟明不明文已经没关系了，咋不说键盘记录器呢。 |
 |
89
dbskcnc 181 天前 via Android
在这个问题上，我完全支持楼主，为什么会有那么多密码库泄露，就因为有这些自以为是的人传输和保存明文密码.
|
|
90
zhenjiachen 181 天前
@InkStone 我没说在前端持久化密码啊，我说的是 bcrypt 哈希是在后端做的并且保存到数据库。
|
|
91
yuyuf 181 天前
@lesismal 啥 token 不 token 的。你都没理解人家说的。他的意思是这个哈希值就是明文密码。
明文比 hash 具有更多的被窥探可能性？。啥叫被窥探可能性？ |
|
92
InkStone 181 天前
@zhenjiachen 不持久化存就根本不需要 AES 加密啊。即使要加密也可以用非对称加密，这样就没有逆向破解的问题。
而且前端可以直接做 nonce+hash 的 bcrypt——至于原因，前面某楼已经说了，哈希跟加密相比，最大的区别是避免后端得知密码明文。 |
|
93
dzdh 181 天前
有罪推定：
既然你是明文传输，那你绝逼往日志里写密码了，还特娘的是明文。你特娘肯定数据库里存的也是明文！！艹！ |
 |
94
janus77 181 天前
我是支持 op 的，我说几个比较极端的例子
1. 网站的员工在后台日志里看到明文密码了，拿去尝试登录 2. 被任何第三方窥探到明文密码了，然后“拿这个密码去试其他网站的登录” |
 |
95
vczyh 181 天前
1.为什么要 HTTPS ？
2.为什么要 HTTPS+加密？ 3.为什么要 HTTPS+加密+签名验证？ 搞清楚 2 为了什么，为了更难破解？没有问题，你可以套 N 层加密，包括自己再实现自己的双向认证。 但这样能说明 1 就不安全了吗？如果是的话，HTTPS 有个毛用，所以我依靠 HTTP 安全性有什么问题？你密码加密，别的 payload 加不加密？ 3 方案也有很多在用，加大爬虫难度等等，那是不是不用就不安全了吗？ 你可以选择任何上面的方案，但没什么最好的，只有更安全，没有最安全，但我个人同意前面有人说的如无必要，勿增实体。 |
|
96
zhenjiachen 181 天前
@InkStone 我是说不赞成前端使用 aes 加密，看清楚哈，前端使用 bcrypt 是认真的吗，前端使用哈希算法，后端保存明文？这就离谱，肯定是前端传输明文后端使用 bcrypt 来做对比。
|
 |
97
cnZary 181 天前
前端是可以篡改的
我既然可以接触到你的设备可以解密 tls 内容 那我加密相关的代码帮你注释掉就好了 中间人的时候再给你加回去 |
 |
98
zengxs 181 天前
能做到 mitm 的肯定得往你的浏览器加根证书，这分为两种情况：
1. 恶意程序添加的。这种情况恶意程序大概率也能控制你的浏览器，他只需要再监控你在浏览器的输入即可，无论前端是否加密你的密码都有可以暴露。 2. 你手动添加的。这种情况应该属于用户自己要避免的。 并且无论哪种方式实现的 mitm ，攻击者都可以通过注入一个恶意脚本来实现获取用户输入的密码，所以任何加密方式大概率都防不了 mitm 。 那么回过头来看密码前端加密，其实这一点能防的就是厂商拿到明文密码了，但是厂商自己开发的程序，他怎么可能会去防自己呢。 很多厂商巴不得多知道你点隐私。 |
 |
99
belin520 181 天前
10 年前，我们接到一个客户的需求，帮他们做了
然后需求我们打上了 “伪安全需求”标签 没有想到 10 年后还有人讨论这个话题 |
 |
100
wanguorui123 181 天前 1
安全是分为不同层级的：
应用层安全：防止暴力破解、防止 XSS/CSRF 、防止 SQL 注入、防止 WebShell 注入 传输层安全：防止中间人对消息篡改和监听、防止消息来源造假 物理层安全：防止数据丢失损坏反转 安全是水桶效应只有每一层都做好安全才行！ |
Select Language