MongoDB中使用的SCRAM-SHA1认证机制

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
简介: 介绍 SCRAM是密码学中的一种认证机制,全称Salted Challenge Response Authentication Mechanism。 SCRAM适用于使用基于『用户名:密码』这种简单认证模型的连接协议。 SCRAM是一个抽象的机制,在其设计中需要用到一个哈希函数,这个哈希函数是

介绍

SCRAM是密码学中的一种认证机制,全称Salted Challenge Response Authentication Mechanism。
SCRAM适用于使用基于『用户名:密码』这种简单认证模型的连接协议。
SCRAM是一个抽象的机制,在其设计中需要用到一个哈希函数,这个哈希函数是客户端和服务端协商好的,包含在具体的机制名称中。比如SCRAM-SHA1,使用SHA1作为其哈希函数。

前言

基于『用户名:密码』这种简单认证模型的协议中,客户端和服务端都知道一个用户名(username)对应一个密码(password)。在不对信道进行加密的前提下,无论是直接使用明文传输『username:password』,还是给password加个哈希的方法都low爆了,很容易被黑客攻击。一个安全性高的认证机制起码应该是具备双向认证的,即:

  1. 服务端需要验证连接上来的客户端知道对应的password
  2. 客户端需要知道这个声称是服务端的人是真正的服务端

我们来看看SCRAM是怎么做的。

初始

  1. 服务端使用一个salt和一个iteration-count,对password进行加盐哈希(使用H表示哈希函数,这里就是SHA1,iteration-count就是哈希迭代次数),得到一个password[s]:

    _password[s] = H(password, salt, iteration-count)_
    
  2. 服务端拿这个password[s]分别和字符串『Client Key』和『Server Key』进行计算HMAC摘要,得到一个key[c]和一个key[s]:

    _key[c] = HMAC(password[s], "Client Key")_
    
    _key[s] = HMAC(password[s], "Server Key")_
    
  3. 服务端保存username、H(key[c])、key[s]、salt和iteration-count,没有保存真正的password

一次认证

  1. 客户端发送client-first-message给服务端,包含username和client-nonce,其中client-nonce是客户端随机生成的字符串
  2. 服务端返回客户端server-first-message,包含salt,iteration-count和client-nonce|server-nonce,其中server-nonce是服务端随机生成的字符串
  3. 客户端发送client-final-message给服务端,包含client-nonce|server-nonce和一个proof[c]。这个proof[c]就是客户端的身份证明。首先构造出这次认证的变量Auth如下:

    _Auth = client-first-message, server-first-message, client-final-message(without proof[c])_
    
    然后使用从服务端获取的salt和iteration-count,根据已知的password计算出加盐哈希password[s],然后根据password[s]得到key[c],再拿这个key[c]和Auth变量经过如下计算得到:
    
    _proof[c] = key[c] XOR HMAC(H(key[c]), Auth)_
  4. 服务端使用其保存的H(key[c])和Auth计算HMAC摘要,再和proof[c]进行异或,得出key[c],再对这个key[c]进行哈希,和其保存的H(key[c])进行比较是否一致。如果一致,则客户端的认证通过,服务端接下来会构造一个proof[s]用来向客户端证明自己是服务端:

    _proof[s] = HMAC(key[s], Auth)_
  5. 客户端使用password[s]得到key[s],然后使用相同算法计算key[s]和Auth的HMAC摘要,验证服务端发送过来的proof[s]是否和计算出来的一致,从而认证服务端的身份。

几个问题

Q:proof[c]为什么不能是和proof[s]一样使用HMAC(key[c], Auth)算得?

A:服务端没有保存key[c],而是保存H(key[c]),这是因为如果服务端的key[c]泄露,那么黑客可以轻易构造出proof[c],从而伪装成客户端了。

Q:那么直接使用HMAC(H(key[c]), Auth)呢?

A:同样,如果服务端的H(key[c])泄露,黑客又可以轻易构造出proof[c],从而伪装成客户端了。因此必须要加上key[c]的异或,从而证明客户端知道key[c]的值。

Q:但是如果服务端的H(Key[c])泄露,再通过网络泄露了proof[c]和Auth,就可以根据proof[c]和HMAC(H(key[c]), Auth)异或得到key[c]了?

A:是的,所以如果要求更高的安全性,还是推荐使用信道加密。

Q:nonce的作用?

A:client-nonce和server-nonce都是随机生成的字符串,这主要是为了每次认证都有个不同的Auth变量,以防止被重放攻击。

安全性分析

分析下以下几种情况下SCRAM的安全性:

  • 网络流量被监听:
    如果某次认证的网络流量被监听,黑客可以拿到salt、iteration-count和Auth,但是无法伪装成服务端,因为没有key[s],无法生成proof[s],完成不了最后一次认证。
  • 服务端被脱裤:如果服务端被脱裤,黑客可以拿到username、H(key[c])、key[s]、salt和iteration-count,但是生成不了key[c],因此无法生成proof[c],不能伪装成客户端。
  • 如果很不幸的网络流量被监听,服务端又被脱裤,那么对不起,被爆菊了,要应对这种情况,只能使用信道加密了。

参考文献

  1. Improved Password-Based Authentication in MongoDB 3.0: SCRAM Explained - Pt. 1
  2. Improved password-based authentication in MongoDB 3.0: SCRAM Explained (Part 2)
  3. 维基百科:Salted Challenge Response Authentication Mechanism
  4. 阿里云MongoDB云服务
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。   相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
目录
相关文章
|
JSON NoSQL MongoDB
mongodb基本操作,增删改查,查询,索引,权限机制
mongodb基本操作,增删改查,查询,索引,权限机制
|
存储 监控 NoSQL
第4期 MongoDB配置用户名密码认证登录
MongoDB配置用户名密码认证登录
3453 0
|
NoSQL 安全 Java
MongoDB:9-MongoDB的安全和认证
MongoDB:9-MongoDB的安全和认证
228 0
|
4月前
|
NoSQL 安全 MongoDB
【MongoDB深度揭秘】你的更新操作真的安全了吗?MongoDB fsync机制大起底,数据持久化不再是谜!
【8月更文挑战第24天】MongoDB是一款备受欢迎的NoSQL数据库,以其灵活的文档模型和强大的查询能力著称。处理关键业务数据时,数据持久化至关重要。本文深入探讨MongoDB的写入机制,特别是更新操作时的fsync行为。MongoDB先将数据更新至内存以提升性能,而非直接写入磁盘。fsync的作用是确保数据从内存同步到磁盘,但MongoDB并非每次更新后都立即执行fsync。通过设置不同的写入关注级别(如w:0、w:1和w:majority),可以平衡数据持久性和性能。
56 1
|
4月前
|
持续交付 C# 敏捷开发
“敏捷之道:揭秘WPF项目中的快速迭代与持续交付——从需求管理到自动化测试,打造高效开发流程的全方位指南”
【8月更文挑战第31天】敏捷开发是一种注重快速迭代和持续交付的软件开发方法,通过短周期开发提高产品质量并快速响应变化。本文通过问题解答形式,探讨在Windows Presentation Foundation(WPF)项目中应用敏捷开发的最佳实践,涵盖需求管理、版本控制、自动化测试及持续集成等方面,并通过具体示例代码展示其实施过程,帮助团队提升代码质量和开发效率。
77 0
|
7月前
|
NoSQL MongoDB 数据库
国内唯一 阿里云荣膺MongoDB“2024年度DBaaS认证合作伙伴奖”
阿里云连续第五年斩获MongoDB合作伙伴奖项,也是唯一获此殊荣的中国云厂商。一起学习MongoDB副本集的选举机制以及可能会出现的特殊情况。
国内唯一 阿里云荣膺MongoDB“2024年度DBaaS认证合作伙伴奖”
|
7月前
|
NoSQL MongoDB 数据库
【MongoDB 专栏】MongoDB 的并发控制与锁机制
【5月更文挑战第11天】MongoDB的并发控制和锁机制保证数据一致性和性能。全局锁用于特殊情况如数据库初始化,限制并发性能;文档级锁提供更高的并发性,针对单个文档锁定。乐观并发控制利用版本号检查减少锁竞争。在分布式环境下,需协调多节点锁,优化包括合理设计数据模型、调整锁配置和利用分布式事务。未来,MongoDB将持续改进这些机制以应对复杂需求。了解并发控制原理对于数据库开发者至关重要。
282 2
【MongoDB 专栏】MongoDB 的并发控制与锁机制
|
5月前
|
存储 NoSQL 关系型数据库
MongoDB的配置服务器和复制机制
【7月更文挑战第2天】MongoDB配置服务器存储分片和权限元数据,支持在主节点故障时保持读服务。关键组件,性能影响显著。复制集包含Primary和Secondary,通过oplog实现数据同步,类似MySQL binlog。oplog的幂等性可能导致大量set操作,且大小受限,可能导致从节点需全量同步。读写分离提升效率,主从切换确保高可用。
58 0
|
5月前
|
负载均衡 NoSQL 中间件
|
7月前
|
NoSQL 安全 MongoDB
MongoDB为提供MongoDB数据库服务的云服务合作伙伴推出认证计划
Certified by MongoDB DBaaS计划还将为云计算合作伙伴提供构建深度技术集成所需的专业支持,同时还将携手MongoDB合作伙伴生态系统(MongoDB Partner Ecosystem)共同推出一系列联合的进入市场举措,使云服务合作伙伴能够助力其客户快速走向成功。
3157 0