SCRAM(Salted Challenge Response Authentication Mechanism)，MongoDB自3.0版本開始使用SCRAM作為其默認的安全認證機制，取代了之前使用的MONGODB-CR。
這篇文檔主要說明的是SCRAM認證機制的設計原理和安全性。

背景

在介紹SCRAM之前，還需要介紹下MongoDB的認證。MongoDB不保存明文密碼，它的認證要求客戶端(Client)提供自身合法性的依據，在3.0版本中，有3種認證機制：

基于密碼的認證（Password-based authentication）：客戶端通過證明預先持有的加密值來驗證身份。SCRAM-SHA-1仍采用這種機制。

基于證書的認證（Certificate-based authentication）：客戶端通過使用x.509認證簽名的受信證書實現身份驗證。

第三方認證：客戶端通過外部第三方服務實現身份驗證，例如Kerberos、LDAP等。

1.1 挑戰-應答協議(Challenge-Response Protocols)

在3.0版本中使用了一種新的基于密碼認證協議，即挑戰-應答協議（Challenge-Response Protocols）。該協議的原理是服務器對客戶端的連接請求都會發起一個問答過程，客戶端需要在回應中證明自己知道真正的密碼。這就像是一個程序員找工作去面試，他不需要在面試現場直接手擼一個系統什么的，最重要的是把思路方法、問題點和解決方案等等細節表達清楚，這樣才能讓面試官相信眼前的這位面試者能勝任這個崗位的工作。

挑戰-應答協議也是這么回事，它需要客戶端來自證身份。這種協議的好處顯而易見，假的真不了，防范了重放攻擊（replay attacks）。那么同樣采用了挑戰-應答協議的SCRAM不僅能做到這一點，它還采用了其他的安全機制以實現防范其他類型的安全攻擊。

1.2 威脅模型(Threat Model)

我們假定黑客可以捕獲和生成任意網絡流量（事實也是如此），并檢查服務器的磁盤存儲內容，同時假設他在運算方面受到限制，因為他也無法突破任何標準密碼原語，比如安全哈希函數。

以下是根據以上威脅模型對SCRAM的一些安全威脅場景。這些都是SCRAM的設計理由，并且實現了應對這些攻擊的策略。

竊聽(Eavesdropping)：攻擊者可以讀取客戶端和服務器之間交換的所有流量。為了防止竊聽，SCRAM客戶端從不在網絡環境下以明文形式發送密碼。

重放(Replay)：攻擊者可以將客戶端的有效響應重新發送到服務器。SCRAM通過隨機數(random nonces)保證每個認證會話唯一，因此協議消息僅對單個會話有效。

數據庫泄露(Database Compromise)：攻擊者可以查看服務器持久內存的內容。通過在存儲密碼之前對密碼進行salting和迭代哈希，可以降低數據庫泄露的風險。

服務器偽裝(Malicious Server)：攻擊者可以充當客戶端的服務器。攻擊者無法在不知道客戶端SCRAM憑證的情況下冒充服務器。

SCRAM

2.1 協議圖(Protocol Diagram)

客戶端啟動SCRAM身份驗證會話

服務端發起challenge應答

客戶端響應challenge，提供proof

服務端驗證客戶端的proof，并提供自己的proof

客戶端驗證服務端的proof

2.2 參考資料

具體的加密過程點我查看。
SCRAM對安全攻擊的防范點我查看。

總結

以上是生活随笔為你收集整理的MongoDB默认使用的SCRAM-SHA1认证机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。