看了最近关于是否应该在 https 协议中明文传输密码想到的
之前部署 MongoDB 的时候,了解到 SCRAM 这个协议:
https://www.mongodb.com/docs/manual/core/security-scram/ https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism
关于网站的登陆验证,网友们基本上分为两派:
其实我个人更倾向于 1 的,但也有一点担心:明文密码可能会被 CDN 服务商看到。这个问题对于能自建 CDN 的大厂来说无所谓,但个人小网站就要考虑该不该信任 cf 或 aws 的问题了。
对于 2 ,其实相当于要在一个不安全的信道上进行登录验证。即用户知道密码,而服务器知道怎么验证密码。这个问题,业界已经有比较成熟的方案,也就是 MongoDB 使用的 RFC5802 SCRAM 协议。据说在 PostgreSQL 、Kafka 和 XMPP 中也使用了这一机制。
https://zhuanlan.zhihu.com/p/650862248
简单地说,在这个协议中,客户端并不是直接传输 hash(密码) ,而是需要跟服务端进行多轮 Challenge-Response 。因为 hash(密码) 是固定的,如果直接传输,黑客也可以拿这个东西直接登录。客户端发送的 challenge 和服务端回应的 response 中都带有随机 nonce ,也就避免了重放攻击。
之前的帖子里也有人问“前端加密或者哈希”的完整方案是什么,这个 SCRAM 协议就是一个完整方案。
所以我挺好奇为啥在网站登录领域没看到有人提 SCRAM ,明明在数据库领域已经有广泛应用。
1
macaodoll 165 天前 via Android
HTTPS 只能保证传输过程的安全,但是对于爬虫来说,请求体没有加密签名之类的东西,就等于脱光了
|
2
hzcer 165 天前 via iPhone 2
增加延迟吧,还可以看看 SRP ,https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol
|
3
moyuge 165 天前
个人觉得使用 RSA 加密足够了,不论是 http 还是 https 场景,前端通过接口获取公钥,公钥加密私钥解密,定期更换密钥对即可。
|
4
cybort 165 天前 via Android
每次选择不同的盐值确实是一个思路,不过没看明白在服务器没有存原文的情况下怎么实现的
|
5
codehz 165 天前 via iPhone
防 cdn 作恶这方面没有任何技术可以解决
因为 cdn 理论上可以直接修改网页内容加上键盘记录器() 毕竟你加密和验证的代码也是通过 cdn 传输的() 某种意义上要想不要泄露密码只能通过无密码方案,例如 passkey ,但即便如此,也无法阻止 cdn 进行会话劫持。 |
8
maggch97 165 天前 via iPhone
算法太难了,99%的开发者大脑理解不了。
就像 V2EX 居然还有这么多人理解不了为什么不明文传输密码。以为是不信任 https 的安全性 |
9
adoal 165 天前 1
要几轮 C-R ,这个就复杂了,尤其是用在 HTTP 这种传统上收发是有序的两阶段、收发完一轮就断开的 stateless protocol 时,不像长连接交错收发的协议上实现起来简单。
|
10
cheng6563 165 天前
因为 Web 有 tls+CA 证书链这种更有效的东西...
无预制 CA 的场景,除非直接拿客户密码当秘钥,其他方案本质上是混淆而非加密 |
11
Divinook 165 天前
SCRAM 和所谓的前端加密有一丁点关系吗?
|
12
coolcoffee 165 天前 1
SCRAM 适合后端服务、App 之间进行通信沟通,但不适合 web 前端这种使用下发脚本来执行的环境。
假如 cf 和 aws 这类 cdn 大厂需要做恶,它可以选择注入脚本监听用户输入框。整个运行环境都不可信任了,谈加密有意义吗? |
13
JKeita 165 天前
SCRAM 和 https 没毛关系吧,应用场景都不一样。
|