这是一个创建于 901 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天登录某些网站时发现对密码进行了加密传输，这样做是防止哪些漏洞？
第 1 条附言 · 2022-05-24 09:53:50 +08:00
感谢大佬们的解答，让我受益匪浅
 |
1
noe132 2022-05-23 16:54:18 +08:00 via Android
理论上没有意义，如果将浏览器认为是可信环境。
|
 |
2
cominghome 2022-05-23 16:54:50 +08:00
多一把锁
|
 |
3
nitmali 2022-05-23 16:56:34 +08:00
中间人攻击、用户敏感信息保密
|
 |
4
chenset 2022-05-23 16:58:10 +08:00  1
接入国内 CDN 后, 它们是能看到明文的
|
 |
5
dcsuibian 2022-05-23 16:58:53 +08:00
确定是加密不是哈希？
|
 |
7
bhyslyk2 2022-05-23 17:00:32 +08:00 2
美国已经有第一岛链了，第二岛链还有意义吗？
你默认 HTTPS 100%安全，但在安全人员眼里根本不存在 100%的安全。 心脏滴血就是一个血淋淋的例子，安全防线不可能只有一条。 |
 |
8
Buges 2022-05-23 17:00:35 +08:00 via Android 3
很有意义，HTTPS 未必可信。你去看 Mozilla 的信任根证书列表，有不少被授信的国产 CA 。
说实话我不了解 CA 授信审查是个怎样的流程，但按理说国产机构如果符合中国法律法规，比如有义务在国家安全需要的情况下签发证书用于对特定 xx 分子破案取证。怎么会符合 CA 授信的标准呢？ |
 |
9
ruixue 2022-05-23 17:01:00 +08:00 9
可能是为了减少整个环节（ CDN 、负载均衡器、Web 服务器等）的攻击面，万一日志配置有误也不会造成明文密码泄露，相当于多加了一道保险。毕竟像 github 和 twitter 这种大厂都出现过日志泄露明文密码的漏洞：
https://www.sohu.com/a/230309592_465914 https://www.sohu.com/a/230826659_175007 明文密码泄露会增加用户的其他服务被撞库的风险，比方说有人在 V2EX 用的密码是 Sbkill1rQlb6xv2 ，那么假如泄露了明文密码，撞库攻击者很可能会按照规律(十步杀一人千里不留行+网站名缩写)猜测这个人在 cloudflare 用的密码是 Sbkill1rQlb6xcf |
|
10
Buges 2022-05-23 17:02:36 +08:00 via Android
另外以上说的是一般业务数据。密码就不应该传输。前端加盐后只传输和存储 hash 才是正常做法。
|
 |
11
kabob OP 感谢各位大佬的解答，原来有这么多方面的问题
|
 |
12
Actrace 2022-05-23 17:19:58 +08:00 1
从现阶段的方案来看，没有意义。
证书加密的方案是基于信任链，cloudfare 发的证书（现在 cloudflare 都是自己签发 SSL 证书来解密你客户端用户的 SSL 流量了，这个信任链是内置于浏览器的），也是看你信不信任它。理论上 cloudflare 可以读取你的所有通信数据（账号密码 balabala...想看就看，如果你用它来传输的话）。即便在浏览器端加密，那么算法和代码是不是得放在浏览器端，算法和代码浏览器调试工具直接可以抓出来。所以，浏览器可能也是一个问题所在，那么你信不信浏览器。 所以现在的公司，如果想要安全性，那只能自己做客户端，自己信任自己。如果想要便利性，那确实直接用浏览器就行。 |
 |
13
wizzer 2022-05-23 17:21:00 +08:00 3
等保测试能通过～
|
 |
14
wanguorui123 2022-05-23 17:25:44 +08:00
多一道防线，多一份安全底线
|
 |
15
lysS 2022-05-23 17:41:28 +08:00 1
加密？不是直接传 hash
|
 |
16
PMR 2022-05-23 17:54:57 +08:00 via Android
|
|
17
Buges 2022-05-23 18:02:19 +08:00 via Android
@PMR 这不是有罪推定，而是法律规定，你可以去看一下国家安全法。
如果他履行要求就无法履行中国法律规定的义务，如果遵守中国法律就无法履行要求。 这就和国内的所有“端到端”加密平台一样，不是信任和有罪推定的问题，而是合规的前提下就不可能做到。 不清楚所谓审计流程是怎么工作的，但我想私下的辅助国家安全部门对少数 xx 分子签发中间人证书用于辅助破案，这种针对特定目标的攻击很难被发现吧？ |
|
18
PMR 2022-05-23 18:35:02 +08:00 via Android 1
@Buges
https://aka.ms/auditreqs https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation 任何商业 CA 都是遵守公司注册地的法律 扯安全法没意义 point 在于 审计机构不会对任何商业 CA 做有罪推定 现在各家基本都有 CT log 部分浏览器也会主动上报 安全性高的应用还会验证自己证书的 fingerprint 在封闭网络环境做攻击 无解 任何一个 CA 都可以攻击 |
 |
19
ic2y 2022-05-23 18:47:57 +08:00
如果不加密， 测试人员可不管是不是 https ，直接把它 标记为一个 S0 级问题，不得发版，还会通报批评。。
|
 |
20
xiangyuecn 2022-05-23 19:03:02 +08:00 1
你的密码也许绕了地球一圈，才被最终的服务器处理。也许集群收到你的请求后，就在内部裸奔，打日志
|
|
21
Buges 2022-05-23 19:16:31 +08:00 via Android
@PMR 恰恰相反，这才是“无罪推定”：即先假定该组织不会违反所在地法律。
其他 CA 组织，如果运营地法律有规定有配合 gov 做中间人攻击的义务的话，我觉得都是不应该采纳的。CA 采信的要求应该加一条：能够合法运营。就像如果开发一个 federated 端到端加密通信工具的话，不应该接受端到端加密不合法的地区运营的节点。 而不可信 CA 最有可能做的就是针对特定目标的攻击，审计只能保证安全（私钥不泄露），但却无法解决这种问题。 |
 |
22
crab 2022-05-23 19:26:46 +08:00
Heartbleed 就能说明了
|
 |
23
jaylee4869 2022-05-23 19:34:43 +08:00
如果你在一个给所有外部域名单独签发了私有 CA 证书的内网环境下，就有意义了。
我现在的公司就是这么做的。 |
 |
24
Tianao 2022-05-23 19:49:13 +08:00 6
有的，ADC 从业者来答一下：很多 SSL offload 之后的流量会在数据中心内部长达数百米到数公里的物理链路中裸奔，而在很多共享 /托管数据中心，保护这些物理链路的只有象征性的机柜围笼、机柜门锁和柜列通道门禁。
|
 |
25
GuuJiang 2022-05-23 20:19:33 +08:00 via iPhone 9
@Buges 前端 hash 是安全问题中最最最典型的一个只知其一不知其二而导致的误解，首先要知道之所以后端存储 hash ，目的是防止被脱裤后泄露密码，但是如果使用方式是前端 hash 并传输，那么脱裤者根本就不需要关心密码明文是什么，此时的 hash 就等于明文，使得后端存储 hash 变得形同虚设
|
 |
26
agagega 2022-05-23 20:25:09 +08:00
某些情况下可以减少日志泄露密码的机会，但这不是一个可以值得依赖的安全实践：
- 没有 HTTPS 的情况下，攻击者从中拿到密码 hash ，依然可以进行重放 - 没有 HTTPS 的情况下，用户加载的一切脚本都可能被动手脚 - 如果 JavaScript 被禁用了怎么办？ |
 |
27
night98 2022-05-23 20:36:30 +08:00 5
前端加密靠不住的，执行文件直接可查看，用 md5 或者 sha1 反而不安全(彩虹表暴力破解)，加盐也毫无意义，是固定盐的话照着再跑一遍仍然没用，非固定盐就又存在另外一个问题，盐从哪获取？
如果已知客户端不可信，那么任何手段都无法阻止用户的密码被泄露，这种就需要引入多因子认证，也就和密码加密没关系了。 https 解决的是 http 传输过程安全性的问题，想要解决客户端不可信的问题只能上硬件方案或者多因素认证，单靠密码是解决不了客户端信任问题的。 反而前端加密引入了更多的问题 1.服务端无法验证是否弱密码 2.服务端无法验证此密码是否已泄露(即其它脱库密码列表中) 3.服务端无法验证密码格式是否符合强密码要求 |
|
28
Buges 2022-05-23 20:40:57 +08:00 via Android 1
@GuuJiang hash 怎么会就等于明文呢，拿了 hash 你就能去其他网站撞库？再者别忘了还有加盐呢。
你要是不理解可以看看 bitwarden 的白皮书 https://bitwarden.com/images/resources/security-white-paper-download.pdf 我可以这样说，如果不能对用户的明文密码保持 zero knowledge ，这个网站大概是打算倒闭后拿用户密码再去其他网站撞一波库。 |
|
29
Buges 2022-05-23 20:43:43 +08:00 via Android
@night98 呃，你这更是暴论。验证是否弱密码不能在前端进行？至于是否已泄露，你去看看哪个查询密码泄露的网站需要提交明文密码的。
|
|
30
GuuJiang 2022-05-23 20:47:42 +08:00 via iPhone
@Buges 我从来没有否定存储 hash ，我否定的是前端 hash 并传输，你举的例子恰恰又一次证明了我的观点，如果全世界都前端 hash 并传输(假设在不加盐的前提下)，存储 hash 变得毫无意义
|
|
31
Buges 2022-05-23 20:55:42 +08:00 via Android 3
@GuuJiang 不知道你怎么得出的结论，hash 为什么不加盐？
好吧就算假设全世界厂商都失了智故意不加盐，那也远远强过传输明文。起码如果我密码是 xxxxx.v2ex 和 xxxxx.github 也不用担心泄露了被撞库。 |
 |
32
jsq2627 2022-05-23 21:01:42 +08:00
有一点意义，但是意思不大。自己的密码传输搞得再安全，面对撞库也会很头疼。
所以现在的主流实践都是假定用户密码一定会泄露，靠 2FA 保证安全 |
 |
33
ysc3839 2022-05-23 21:09:03 +08:00 via Android
@GuuJiang #25 前端进行 hash 运算后再传输不等于后端收到数据后原样保存。后端收到数据后，使用安全的 hash 算法运算后再保存到数据库，攻击者拿到数据库中的数据后，确实是不需要关心密码明文是什么，但仍要关心密码经过前端的 hash 运算后的结果是什么，为什么这会“使得后端存储 hash 变得形同虚设”呢？
|
 |
34
choury 2022-05-23 22:20:34 +08:00
@ysc3839 #33 只需要把 hash 后的值当密码发送给后端就可以校验过了，并不需要知道源密码，因为后端也不能知道前端是否经过了 hash 这个步骤
|
|
35
GuuJiang 2022-05-23 22:43:10 +08:00 via iPhone
@Buges
@ysc3839 所以我说这个误解是多么的典型，因为会犯这个错误的人不少，类似的问题随便动动手就能搜到一大把 https://stackoverflow.com/questions/3391242/should-i-hash-the-password-before-sending-it-to-the-server-side 你一直在说撞库，请问防止撞库的手段是传输 hash 吗？不是，是存储 hash ，而传输 hash 的行为大大降低了存储 hash 的意义，极端情况下降为 0 ，你可以继续坚持自己的观点并在实际项目中使用前端 hash 并传输，但是麻烦告知下这样的项目地址以供避雷 |
 |
36
mikywei 2022-05-23 23:27:27 +08:00
当然有了，因为你登录用户名密码用明文，直接就可以爆破你了。当然防止爆破也不止这一种方式，但加密也是很有效的，要爆破你还要猜你是怎么加密的，成本升高很多的，基本看到加密就不搞你了。
|
 |
38
yeqizhang 2022-05-24 00:28:23 +08:00 via Android
别说了，某些等保连个身份证都要求加密传输
|
|
39
ysc3839 2022-05-24 00:36:34 +08:00 via Android
|
|
40
Buges 2022-05-24 00:47:06 +08:00 via Android 5
@GuuJiang hash 之后还可以再次 hash ，不过我说的重点不是这个，而是将原始明文密码发送到后端的不可靠性。
脱裤后泄露最大的危害是撞库，某个网站自己被脱了他肯定有补救措施，比如强制两步验证、暂停登录等。但其他网站就不行了。只要加盐 hash 至少一次就可以确保 A 站脱的库无法威胁到 A 站以外的其他网站的用户帐户，这才是最关键的。 另外如果前端将明文密码发送到后端，那这个服务就是不可信的，你没法验证他到底有没有存储明文。除了内鬼泄露、脱裤被拿去撞库以外，很多不使用密码管理器的用户的明文密码中同时 encode 了如生日、名字拼音等隐私信息，可以在社工的时候提供相当的参考。 |
 |
41
fenghengzhi 2022-05-24 02:13:05 +08:00 via Android 1
|
 |
42
Puteulanus 2022-05-24 03:28:57 +08:00
前端 hash 怎么加盐，在验证密码正确之前就得把盐传给他。。
攻击者不知道“明文密码”的前提是“别的网站都传的是明文密码”，如果所有网站都用的同一种 hash 方式的话，这个 hash 就是以前的明文，hash 这个操作只是网页上做的一种快捷输入。。就像用了 1password 之后可以说“明文密码”是 “command + enter”，但这个没意义，相对的所有网站的密码都是它输进去那个十几位的东西，那个才是明文密码 你不能既要推广一个标准，它的安全又是建立在其他人不用这个上的。。这就自己造密码学轮子的思维，像什么 md5(md5) 比 md5 更安全。。 |
 |
43
dingwen07 2022-05-24 06:23:14 +08:00 1
|
 |
44
g531956119 2022-05-24 08:30:23 +08:00 via Android
@GuuJiang 这个问题底下最高票的答案，就是支持前端传 hash 并加盐的
|
 |
45
Felldeadbird 2022-05-24 09:19:01 +08:00
在安全环境下，可以忽略。只是现实中使用场景很复杂。有精力可以前端加密一下。
|
 |
46
springz 2022-05-24 09:53:35 +08:00
不一定，要看你这个 https 加在哪里，现在一般都有 CDN LB WAF 之类的，如果直接到到你后端服务没问题，但是如果 nginx 等等中间经过的层有日志之类的就存在泄漏用户明文密码的风险。最少前端 Hash 一下后端保存再加盐 Hash 一下。
|
 |
47
dongtingyue 2022-05-24 10:04:06 +08:00
lz 想说的应该是自己用 rsa 加密下吧。直接到自己站点的没问题，套 cdn 有问题
|
 |
48
keyfunc 2022-05-24 10:14:22 +08:00 3
@Buges 国内 CA 从业者来来解释下。就目前的规则来说，CA 是不可能配合做中间人攻击的，因为成本太高了。CT 的存在，热门网站的中间人太容易被发现了。只要有一次中间人的记录，基本上下年的审计你就别想过了。你可能认为审计会配合造假，但目前有资质做 webtrust 审计的都是 CPA 许可的，当年 CNNIC 的事件可是直接把 EY 的 webtrust 审计资格给取消了。再说了我朝一般的做法是直接搬走你的服务器，还用得着找 CA 配合你做中间人？
|
 |
49
dzdh 2022-05-24 10:15:04 +08:00
前端加密没意义。
|
 |
53
ytll21 2022-05-24 10:21:39 +08:00
没有意义，因为如果不信任 https ，那么就代表不光是密码，其它业务数据都有可能泄漏。
那么怎么避免这种问题？最终方案只能是自己实现一个 https ，把全部的数据按照自己的协议来加密。 否则只加密密码，单纯只是增加了代码 kpi 而已。 |
 |
54
bdnet 2022-05-24 11:38:52 +08:00
安全是相对的，账号安全目前普遍的做法：二步验证。更高级别硬件级密钥。
|
 |
55
zpf124 2022-05-24 13:51:30 +08:00 1
@dingwen07
@g531956119 @Buges 你们说的东西和人家 @GuuJiang 说的是两个概念。 人家说的是 即便监听者拿到的是前端哈希后的值，那在当前网站依然被黑了，对于本站和明文传递没区别。A 网站的用户在 A 网站的密码还是暴露了，攻击者可以随意登录。 而你们在说攻击者拦截了流量会危害到使用相同账号密码的其他网站，A 网站用户泄露的密码会导致 BC 网站同样被可以攻击者登录。 我赞同你们说的存在的问题，但这个问题和人家提的点关联性不大，即便按你们说的加 hash 了，那人家提的 A 网站被攻破了的问题你们并没有扛住了，那为什么说的好像人家说错了一样。 |
|
56
zpf124 2022-05-24 13:53:06 +08:00
而且 https 被监听的问题我觉得不会如后端被脱裤那样容易引起大范围反应，https 要被攻击者解密我只知道让用户手动信任中间人的证书这一种情况。
除此之外我只听说过只有之前沃通还是那个 CA 的 bug 会给人发 gitpage.io 的根域名证书，然后这个 CA 就被浏览器火速拉黑了。 |
|
57
zpf124 2022-05-24 14:01:19 +08:00
@dingwen07
@g531956119 @Buges 我赞同 @GuuJiang 的观点，前端不要闲得没事自己做哈希，你们是准备把弱密码库之类的也写个 js 库自己前端做校验吗？然后弱密码策略也前端自己维护一份？比如什么密码包含生日包含连续数字包含账户名这种？ 当然如果做加密我不反对，尤其是用非对称的，前端 js 里固定公钥就行，后端可以在注册和登录的时候照常反解回来，然后各种安全服务可以照常调用，弱密码相似密码也都不用前端处理，就是后端高并发的性能会差一些。 |
|
58
zpf124 2022-05-24 14:11:13 +08:00
当然 @GuuJiang 也理解错了一点他们的说法， 他们的说法是说 前端后端各做自己的哈希。
数据库存储的密码在他们的设计里是 后端:hash( 前端:hash(用户输入+前端固定 salt) + 每个用户个人 salt)。 这在后端眼里只是对于本站而言，等于脱了裤子放屁，用户密码由 123 变成了 a2cf ，但攻击者拿到的就是 a2cf ，拿到就能登录，对后端完全没区别。 |
|
59
Buges 2022-05-24 14:51:38 +08:00 via Android
@keyfunc 我倒不是觉得审计造假。事实上我相信目前的审计可以确保不会出现大范围的中间人攻击，如果国家有这个需要可以强制安装或让流氓软件偷偷安装自己的私有 CA 证书。我担心的是在完全可控的网络环境下针对特定目标的攻击。 至于搬服务器没啥意义，这里指的肯定是不受控制的目标。
|
|
60
Buges 2022-05-24 14:58:40 +08:00 via Android 1
@zpf124 你再仔细想想。拿到后端 hash 后的结果不等于拿到前端 hash 后的结果。
前端 hash 和后端 hash 是两个截然不同的安全层。前者的意义在于让后端不能接触到用户的明文密码，对用户的密码保持 zore knowledge 。而后者是阻止本站被脱裤后攻击者登录本站用户的账号。我上面主要强调第一点因为我觉得第一点更重要，因为本网站被拖总是有感知的，有感知就有办法补救。其他网站撞库才是最大的威胁。 而你们说的好像一但做了第一点就不能再做第二点了，事实上做不做第二点是另一个问题，与第一点没什么关系。 具体的例子可以去看看 bitwarden 的白皮书。 |
 |
61
lakehylia 2022-05-24 15:37:16 +08:00
说一句，国内现在密码登录等同虚设了，手机验证码代替了密码。。。
|
 |
62
vishun 2022-05-24 15:37:52 +08:00
@GuuJiang #25 正常来说前端加密压根不用 hash ，而是类似用 rsa 加密，前端密码加密后，后端根据解密出明文密码，然后再用后台的 hash 来匹配数据库，压根说的不是一个东西。
|
 |
63
0zero0 2022-05-24 16:04:36 +08:00
通过这个帖子感受到了技术辩论的好处和意义……感谢
|
 |
64
yEhwG10ZJa83067x 2022-05-24 16:06:45 +08:00
@wizzer #13 我靠，我也想说这个
|
|
65
keyfunc 2022-05-24 17:17:58 +08:00
@Buges 其实还是成本问题，一家 CA 从提交预埋申请到完成预埋周期是很长的，Mozilla 起码需要 2 年，微软、Google 、Apple 这些商业机构的预埋前置条件是完成 Mozilla 的流程，别说还有 oracle 、黑莓这些联系都很难的机构。WebTrust 每年的审计费用和 PKI 基础设施的相关费用也是非常高的。就算你完成了所有预埋，但要保证预埋的根证书有良好的兼容性，需要一个非常久的沉默期，这个期限可能是 3-4 年。CA 确实有能力实施中间人攻击，但这么做的代价就是别做这块业务了，CA 与浏览器之间有公益性的交流机构 CABFourm ，所有的证书规则基本由这家机构制定的，目前对 CA 的主观恶意行为是 0 容忍的。
|
|
66
zpf124 2022-05-24 17:29:07 +08:00
@Buges 我承认你说的这个问题，但我个人还是认为 https 不太容易被攻击，前端 hash 的缺点高于优点。
同时我说了我觉得前端要做可以做非对称加密 |
 |
67
findex 2022-05-24 17:59:56 +08:00 via iPhone
脱裤的时候让对方费电事
|
|
68
Buges 2022-05-24 19:05:18 +08:00 via Android
@zpf124 前端 hash 和后端 hash 是互不影响、完全无关且相互独立的两件事。前者是为了避免撞库和保持 zero knowledge ，无论后端是否 hash 。后者是为了避免脱裤后登录，无论前端是否 hash 。
至于公钥加密同上，后端依旧能得到用户的明文密码。 前端 hash 唯一的缺点就是倒闭了之后不能卖用户的秘密库。 |
 |
70
wonderfulcxm 2022-05-24 20:21:31 +08:00 via iPhone
前端 hash 纯属脱裤子放屁，我没见哪个知名大厂这么用的。
|
 |
71
tool2d 2022-05-24 20:33:05 +08:00
一般情况下加密意义不大，但是如果遇到真心想破解你网站 API 的黑客，那就另当别论了。
|
 |
73
GeruzoniAnsasu 2022-05-24 21:31:18 +08:00
@Buges 如果把「认证要素」（无论是 plain password 还是 access token ）视为 knowledge ，后端是无论如何必须知情的。后端不可能在不接触 auth chellenge 的情况下给出判定，因此「认证要素」是必须放在客户端信道中传输的。
换句话说，假如信道不安全，无论密码有无实现 hash ，中间人总是能复制出一个后端无法分辨的 chellenge 。chellenge 内容是 plain text 还是 hash 根本不重要，中间人能完整复制且通过后端验证。这是信道安全的必要性。 然后再讲充分性，即是否「只要信道安全则认证安全」；可以用其逆否来判断，即是否「认证不安全一定说明是信道不安全」。我们会发现存在比如「用户泄露自己的凭证」这种条件，所以仅当「泄露凭证」等条件不成立时才可以认为信道安全是认证安全的充分条件。（我暂时没想到其它条件，因此所有下文提到的「凭证泄露」条件都是此处反例条件的 并集，这个并集暂时只有一个元素。） 因此引理 1: auth 的安全性取决于信道安全，当且仅当凭证未泄露 第二步，我们讨论这个系统在任意情况下是否会导致凭证泄露。很容易会发现假若凭证存储等于凭证原文时凭证有可能泄露，而当凭证存储不完全独立于其它关联信息时（比如用户个人信息），也有导致泄露的可能性，其余情况不可能泄露。 因此引理 2: 当且仅当凭证存储的内容完全独立于关联性数据，且无法根据存储还原出凭证原文时，「凭证泄露」不可能发生 看这两个引理： 1. 当凭证不泄露时信道安全是认证安全的充要条件 2. 当凭证存储于原文和相关信息都完全独立时凭证不可能泄露 我们可以得出结论： 只要传输的认证要素与用户相关信息完全独立且信道是安全的，那么认证就是安全的。 用密码的一大问题是它跟用户信息往往存在相关性，因此使用密码原文作为认证要素有泄露密码的风险。但注意这不是因为脱库能拖出密码，也不是因为密码被撞了。我们现在讨论的是单一系统的安全性。是在说如果库记录完全公开了，这个用户的密码是否有被还原的可能性。如果他的密码本身就非常随机，即使库被公开了，密码也是不可能泄露的（不考虑 hash 被爆破的可能性）。 再强调一下，至此为止我们只考虑单一系统的安全性，不考 hash 能从已知明文撞出来的情况。 然后第三步，我们才来考虑多个这样的系统同时存在的场景。很容易发现由于引理 2 ，只要两个系统存在同样的密文，那么这两个系统就有可能发生相互泄露，因为此时「另一个库的密文」就是「本库密文」的相关数据了。换言之如果一个库存储的凭证被泄露了，是有可能发生另一个库的凭证泄露，从而破坏另一个系统的认证安全的。不过在单系统场景的假设下，凭证是可以不存在泄露可能的，即使凭证可以从一个系统泄露到另一个系统，但第一个泄露本身不可能发生。 综上总结一下我在实行和可得出结论的： 1. 前端加密没有用，因为它不增加信道安全性。顶多增加凭证密文的独立性，但假如我密码足够随机，在可信信道中传递密码还是 hash 过的密码有什么所谓呢 2. 多系统共用密码且共用了 hash 方法的话很可能会发生撞库，但只要保证每个这种系统即使数据库公开也无法还原我的密码，那我大可以就只用一个密码，想撞库，没材料。 3. 所以我现在的密码是分级的 - 垃圾不信任级：我感觉这网站的密码没准是明文存的，那么避免使用密码，只使用 otp 如短信验证码这种认证方式。因为对于这些网站来说密码根本是冗余的、无效的认证信息。 - 可信级，我觉得这网站的密码存储机制是足够科学的，即使库爆了应该也不能还原出密码。这些网站我全都使用同样的随机密码，因为记随机密码的心智负担有点大，我只能记一两个 - 高安全等级，存了我大量个人信息和记录的，绝对要杜绝任何认证被攻破可能性的，比如 google qq 这种，每个网站使用完全不同的密码，我有一套生成规则 4. 我不使用密码管理器。因为无非是把撞库风险面从远程服务器转到了个人设备上。而个人设备很容易使人掉以轻心，比如相信不少人密码管理器的 pin 就不会很复杂了对吧 5. 开发要登录的业务系统，不进行任何传输层上的变形，比如什么前端 hash 这种，没用。when in need 套 TLS |
 |
74
sutra 2022-05-24 21:33:37 +08:00
说得好像不启用 http ，密码加密传输就有意义似的。
|
|
76
Buges 2022-05-24 22:12:57 +08:00 via Android
@GeruzoniAnsasu 你扯的太偏了。我上面说了多少遍，加盐 hash ，每个网站每个用户的盐都不一样，哪来的“明文撞出来”、“同样的密文”。要是每个用户都为不同网站使用不同随机密码就没那么多事了，但事实上不是这样，他们的密码常常简单、一样、包含其他隐私信息，你说该不该加盐 hash ？
从用户的角度来说，发送明文（或可还原出明文的密文）密码是无法证明服务商没有存明文的。所以服务商只要注重安全，保持对用户明文密码的 zero knowledge 是至关重要的。access token 和明文密码的区别，不用我再赘述。 至于密码管理器怎么和撞库联系起来我暂且蒙古，用了密码管理器你只需要一个足够复杂的主密码（或配合密钥及 yubikey 等介质），该密码从来不在任何其他地方使用，也不会以任何形式传输和存储。你的个人设备根本从无法公网访问，怎么会被撞库？就算你本人是高价值人士，也有 veracrypt 这种提供 plausible deniability 的工具。使用密码管理器可以所有帐户全随机强密码，任何形式的撞库的影响不到你。按你说的那样用一样或有规律的密码，如果对方明文存储，可以以此识别你的身份。 |
 |
77
lululau 2022-05-24 22:14:11 +08:00
我只想知道，https 的前提下是怎么做到密码不加密的。。。
|
|
78
Buges 2022-05-24 22:15:04 +08:00 via Android
@zpf124 我见过的所有弱密码判断，都是检测字符集范围，就是判断是否有符号、数字、大小写字母这些，没见过什么穷举。
至于已泄露密码判断，发送 hash 后的结果到检测接口即可。 |
|
79
GeruzoniAnsasu 2022-05-24 22:19:48 +08:00
|
|
80
Buges 2022-05-24 22:34:29 +08:00 via Android
@GeruzoniAnsasu 你扯一堆晦涩的论证并不能掩盖结论的错误。前端 hash 的作用我上面已经说了很多遍了，“假如你密码足够随机”你是不是忘了还有其他用户的密码不够随机？
你没耐心去看一眼我上面发的 bitwarden 的白皮书的话，思考这个问题： 如果前端不发送 hash 后的结果到后端，我如何证明自己无法解密用户的数据？ |
 |
81
liuhan907 2022-05-24 23:23:05 +08:00 via Android
@Buges
强弱检查前端是比较好做，但是泄漏检查要只发送 hash 后的密码的话你还得把泄漏的密码也全部做一次加盐 hash ，是不是太浪费？ |
|
82
Buges 2022-05-24 23:31:02 +08:00 via Android
@liuhan907 浪费？你去看看那些泄露检测的网站，还有不少商业密码管理器自带的泄露检测功能，要是有哪个上传明文密码，赶紧去 hn 发帖把它批倒批臭。
再者说这种情况也不需要加盐，常规做法是 hash 后取一小段发送到检测接口，如果有命中则把命中项取回前端再比对。 |
|
83
liuhan907 2022-05-24 23:40:21 +08:00 via Android
@Buges
为了以防我记错了我又确认了一下，Twitter 和 GitHub 登录都是直接发送明文，我觉得似乎这两家也没被喷啊。 |
|
84
Buges 2022-05-24 23:48:03 +08:00 via Android
@liuhan907 这是普通网站登录啊，虽然直接发明文不是最佳安全实践但也不会被喷。但密码泄露检测是要你输入其他网站的密码，这种情况下上传明文就过分了。
标榜隐私加密的服务，如 1password 、protonmail 、mega 等，都不会发送明文。 |
|
86
Buges 2022-05-24 23:53:28 +08:00 via Android
@liuhan907 这与泄露没关系啊，我是 GitHub ，我上传你的 GitHub 密码这很正常。但如果我就一第三方，我上传你其他网站的密码，这是检测呢还是钓鱼呢，收集的数据是不是还要完善一波裤子。
|
|
88
liuhan907 2022-05-24 23:55:59 +08:00 via Android
|
|
89
Buges 2022-05-25 00:05:26 +08:00 via Android
@liuhan907 hash 的意义我上面说过很多遍了。大厂传明文，说明大厂并不想对你的密码保持 zero knowledge ，很多用户的密码中可以提取出不少隐私信息。
而凡是以安全、隐私为卖点的服务商，和加密存储用户数据（并且宣称他们自己也无法解密），是不会让服务器接触用户主密码的。还有一个常见的例子是 Firefox sync 。https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ |
|
90
GeruzoniAnsasu 2022-05-25 00:12:33 +08:00 1
@Buges
> 假如你密码足够随机”你是不是忘了还有其他用户的密码不够随机？ totally agree. 所以前端 hash 的作用仅仅是帮助减少密码泄露的风险面而已，对验证这个过程的安全性没有多大帮助。 ------ > 如果前端不发送 hash 后的结果到后端，我如何证明自己无法解密用户的数据？ 所以你有没有发现你试图用「 zero knowledge ENCRYPTION 」去论证传输一个 hashed password 是 auth 的必要条件 —— 但这根本不是用于登录的。 其实从你 #28 拿出这个来附会撞库和加盐就能感觉出你好像混淆了不少东西 1. 套上任意多的密码学机制当然会「更安全」，但不一定都有意义。这跟 hash 一次还是 hash10 次没区别是一个道理 2. 不接触用户数据的后端并不是典型场景，零信任 /零知识不是每个系统的必要条件，也不是登录 /身份验证机制的必要条件 3. 我存了用户的 salted-hashed-password ，也不可能拿出来去其它网站撞库。被撞站点的数据库公开且 hash 过程相同且密码原文相同，这是一个极其苛刻的条件 4. 不管前端是否先对 password 进行 hash ，数据库里的 password hash 反正都是「零知识」（不能还原出 password 到底是什么）的。对于用户来说，自己的密码已经必不可能由于机制缺陷泄露到第三方了，仅仅是第一方是否有权接触到密码这个问题而已，那这其实跟第一方是否有权访问用户个人信息是一回事，都已经是与登录无关的另一个层面了 ----- 其实有一个问题可以用来自我检验到底有没有想清楚：「如果登录过程完全没有用户密码，仅使用个人证书，会比在 SSL 中传输同等长度的随机明文密码更安全吗」 答案是不会。 |
|
91
Buges 2022-05-25 00:27:44 +08:00 via Android
@GeruzoniAnsasu 所以加盐 hash 后，所有用户的“auth token”就都足够随机了。
hash 当然不是 auth 的必要条件，它与 auth 完全无关，但这并不等同于你所宣称的“无意义”。 hash 后再传用户可以确定你没存明文，传了之后用户就不知道你到底存没存了。 安全领域的一个典型原则：权限越少，攻击面越小。也许你你打算后端 hash 后再入库，但明文已经被存储记录在日志中了。 |
|
92
dingwen07 2022-05-25 05:14:58 +08:00 via iPhone
@zpf124 #55
本身数据库存储 Hash 而不是密码明文就是为了防止离线攻击的，对于防止自己的网站被攻破没有意义。 毕竟人家都拿到你数据库了，很多时候没必要正确用正常的登录接口访问数据了吧。 前端 Hash 的好处是可以证明用户的密码网站不知道，虽然我估计没有几个网站会这么做，也没有多大必要。 |
|
93
GeruzoniAnsasu 2022-05-25 06:39:46 +08:00
@Buges
日志里出现一个明文密码还是出现了一个 hash 过的密码，这个密码能不能用于突破登录只取决于日志的位置。「权限越少攻击面越小」非常对，可是把密码 hash 一下再传输根本没有减少任何权限。 拿你如此熟悉的 bitwarden 白皮书来说， 它用来什么手段减少第一方的权限？难道是 hash 一下 password 的功劳？ 并不是，功劳是用户数据是加密的。加密用户数据才是减少权限的方法，它所做的所有这一切是保证加密是可信的。 你有没有想过  如果 HTTPS 不生效，这个系统的结果是啥 答案是，可以登录，但解密不了数据。 可以登录。 |
|
94
0zero0 2022-05-25 11:31:29 +08:00
@GuuJiang @Buges @GeruzoniAnsasu
按个人理解简单总结一下当前的讨论情况： 1. 如果网站用户的期望是即便 A 网站被搞了（不管是被黑客入侵 /拖库，还是被内部开发 /测试或是其他人员非法利用，亦或是什么其它的方式），也不要影响到该用户在其它 B/C/D 网站的 [密码安全性] ，这种情况下，在前端就把密码进行 [hash] 处理对于该用户来说是 [有一定意义] 的。因为这种情况下，在后面的网络传输以及该网站后端拿不到用户的明文密码，不论是网站流量被解密监听还是该网站被黑了或是出现日志配置错误等问题，其它人正常情况下都很难还原出用户的明文密码（在不考虑超级彩虹表反向映射的情况下）。 但这么做（在前端就把密码进行 [hash] 处理）的好处，也基本上就这么多了——而且主要集中在那些会在密码中掺杂生日、名字拼音等隐私信息的用户上。如果不想让别人知道这些信息，最好的办法还是用密码管理器对各网站都生成并使用随机密码（虽然在实际使用上很难完全做到），一个是各网站密码不同，另一个是不暴露隐私信息。 如果网站被黑了，或是该网站后端有人通过日志等方式直接拿到了 hash 后的密码，他通过分析网站的登录接口最后还是可以进行登录并拿到用户的权限，对于该网站内用户权限的安全性并无实质性帮助。 2. 按 stackoverflow 以及本主题上面的回复来看，很多大网站并没有采用在前端对密码进行 hash 处理的方式，一方面是这样做对安全实质性的提升帮助不大，另一方面也是他们对用户的密码还有一定的企图心（也许真像上面回复中提到的“打算倒闭后拿用户密码再去其他网站撞一波库”）。 |
 |
95
yedanten 2022-05-25 13:33:11 +08:00 via Android
从安全角度来看，意义不大，过等保之类的合规性检查的意义更大
|
|
96
Buges 2022-05-25 14:32:16 +08:00 via Android
@GeruzoniAnsasu hash 以后让后端无法访问到（不需要的）明文密码，这就是减少的权限。
至于第二个问题，不 hash 密码的话用什么 key 加密才能保证只有用户能解密呢？ |
Select Language