为什么 SCRAM 协议没有更广泛地应用于网站登录验证

[henix]

看了最近关于是否应该在 https 协议中明文传输密码想到的

之前部署 MongoDB 的时候，了解到 SCRAM 这个协议：

https://www.mongodb.com/docs/manual/core/security-scram/ https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism

关于网站的登陆验证，网友们基本上分为两派：

1. 用了 https 就可以在里面传明文
2. 不信任 https ，还要搞一套自己的加密 or hash

其实我个人更倾向于 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 ，明明在数据库领域已经有广泛应用。

[macaodoll]

HTTPS 只能保证传输过程的安全，但是对于爬虫来说，请求体没有加密签名之类的东西，就等于脱光了

[hzcer]

增加延迟吧，还可以看看 SRP ，https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol

[moyuge]

个人觉得使用 RSA 加密足够了，不论是 http 还是 https 场景，前端通过接口获取公钥，公钥加密私钥解密，定期更换密钥对即可。

[cybort]

每次选择不同的盐值确实是一个思路，不过没看明白在服务器没有存原文的情况下怎么实现的

[codehz]

防 cdn 作恶这方面没有任何技术可以解决
因为 cdn 理论上可以直接修改网页内容加上键盘记录器（）
毕竟你加密和验证的代码也是通过 cdn 传输的（）
某种意义上要想不要泄露密码只能通过无密码方案，例如 passkey ，但即便如此，也无法阻止 cdn 进行会话劫持。

[lisxour]

@moyuge 百度贴吧就是这么干的，防止了大部分的常规攻击场景

[abelyao]

@codehz 不需要上键盘记录器，只要在 onClick 之后、hash 之前，加一行代码就可以把明文密码拿走了

[maggch97]

算法太难了，99%的开发者大脑理解不了。

就像 V2EX 居然还有这么多人理解不了为什么不明文传输密码。以为是不信任 https 的安全性

[adoal]

要几轮 C-R ，这个就复杂了，尤其是用在 HTTP 这种传统上收发是有序的两阶段、收发完一轮就断开的 stateless protocol 时，不像长连接交错收发的协议上实现起来简单。

[cheng6563]

因为 Web 有 tls+CA 证书链这种更有效的东西...

无预制 CA 的场景，除非直接拿客户密码当秘钥，其他方案本质上是混淆而非加密

[Divinook]

SCRAM 和所谓的前端加密有一丁点关系吗？

[coolcoffee]

SCRAM 适合后端服务、App 之间进行通信沟通，但不适合 web 前端这种使用下发脚本来执行的环境。

假如 cf 和 aws 这类 cdn 大厂需要做恶，它可以选择注入脚本监听用户输入框。整个运行环境都不可信任了，谈加密有意义吗？

[JKeita]

SCRAM 和 https 没毛关系吧，应用场景都不一样。