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

看了最近关于是否应该在 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 ，明明在数据库领域已经有广泛应用。