SCRAM(Salted Challenge Response Authentication Mechanism)，MongoDB自3.0版本开始使用SCRAM作为其默认的安全认证机制，取代了之前使用的MONGODB-CR。
这篇文档主要说明的是SCRAM认证机制的设计原理和安全性。

背景

在介绍SCRAM之前，还需要介绍下MongoDB的认证。MongoDB不保存明文密码，它的认证要求客户端(Client)提供自身合法性的依据，在3.0版本中，有3种认证机制：

1. 基于密码的认证（Password-based authentication）：客户端通过证明预先持有的加密值来验证身份。SCRAM-SHA-1仍采用这种机制。
2. 基于证书的认证（Certificate-based authentication）：客户端通过使用x.509认证签名的受信证书实现身份验证。
3. 第三方认证：客户端通过外部第三方服务实现身份验证，例如Kerberos、LDAP等。

1.1 挑战-应答协议(Challenge-Response Protocols)

在3.0版本中使用了一种新的基于密码认证协议，即挑战-应答协议（Challenge-Response Protocols）。该协议的原理是服务器对客户端的连接请求都会发起一个问答过程，客户端需要在回应中证明自己知道真正的密码。这就像是一个程序员找工作去面试，他不需要在面试现场直接手撸一个系统什么的，最重要的是把思路方法、问题点和解决方案等等细节表达清楚，这样才能让面试官相信眼前的这位面试者能胜任这个岗位的工作。

挑战-应答协议也是这么回事，它需要客户端来自证身份。这种协议的好处显而易见，假的真不了，防范了重放攻击（replay attacks）。那么同样采用了挑战-应答协议的SCRAM不仅能做到这一点，它还采用了其他的安全机制以实现防范其他类型的安全攻击。

1.2 威胁模型(Threat Model)

我们假定黑客可以捕获和生成任意网络流量（事实也是如此），并检查服务器的磁盘存储内容，同时假设他在运算方面受到限制，因为他也无法突破任何标准密码原语，比如安全哈希函数。

以下是根据以上威胁模型对SCRAM的一些安全威胁场景。这些都是SCRAM的设计理由，并且实现了应对这些攻击的策略。

1. 窃听(Eavesdropping)：攻击者可以读取客户端和服务器之间交换的所有流量。为了防止窃听，SCRAM客户端从不在网络环境下以明文形式发送密码。
2. 重放(Replay)：攻击者可以将客户端的有效响应重新发送到服务器。SCRAM通过随机数(random nonces)保证每个认证会话唯一，因此协议消息仅对单个会话有效。
3. 数据库泄露(Database Compromise)：攻击者可以查看服务器持久内存的内容。通过在存储密码之前对密码进行salting和迭代哈希，可以降低数据库泄露的风险。
4. 服务器伪装(Malicious Server)：攻击者可以充当客户端的服务器。攻击者无法在不知道客户端SCRAM凭证的情况下冒充服务器。

SCRAM

2.1 协议图(Protocol Diagram)

1. 客户端启动SCRAM身份验证会话
2. 服务端发起challenge应答
3. 客户端响应challenge，提供proof
4. 服务端验证客户端的proof，并提供自己的proof
5. 客户端验证服务端的proof

2.2 参考资料

具体的加密过程点我查看。
SCRAM对安全攻击的防范点我查看。