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

查看 31|回复 2
作者:henix   
看了最近关于是否应该在 https 协议中明文传输密码想到的
之前部署 MongoDB 的时候,了解到 SCRAM 这个协议:
https://www.mongodb.com/docs/manual/core/security-scram/
https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism
关于网站的登陆验证,网友们基本上分为两派:
[ol]
  • 用了 https 就可以在里面传明文
  • 不信任 https ,还要搞一套自己的加密 or hash
    [/ol]
    其实我个人更倾向于 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
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部