我最近更新了Mongometer ，使其更加靈活。 發布新版本后不久，其中一位用戶通過在帖子中發表評論來反饋問題。 我啟動了我的機器，打開了我的IDE，發現了問題，并在半小時內將修復程序推送到了github 。 這不是快速的成功案例。 我很快就意識到，如果將來我要使用Mongometer做任何事情，我真的應該對用戶如何對MongoDB中的數據庫進行身份驗證有更多的了解。 （我不想花一個多小時左右，因為我剛剛打開了一瓶Nyetimber Classic Cuvee –我也正在煮雞肉派（如果需要的話可以給我蓋上鍋），我而不是在完成瓶子之前完成這篇文章。）在深入探討MongoDB Security可能存在的任何文檔之前，我將從一些觀察開始。
因此，以典型的男人風格，讓我們踢一下輪胎，然后如果需要，再踢RTFM。 啟動一個mongod實例。

$ /usr/lib/mongodb/2.3.2/bin/mongod --port 27001 --fork --dbpath /data/db/2.3.2 --logpath /data/db/2.3.2/mongod.log $ ./mongo --port 27001

創建一個管理員用戶

> use admin > db.addUser('mongouser','mongopass') 1

重新啟動mongod

$ sudo kill -15 $(ps -ef | grep mongo | grep -v grep | cut -f8 -d' ') $ /usr/lib/mongodb/2.3.2/bin/mongod --port 27001 --fork --auth --dbpath /data/db/2.3.2 --logpath /data/db/2.3.2/mongod.log $ ./mongo --port 27001

驗證給管理員

> use admin switched to db admin > db.aut('mongouser','mongopass') Thu Jan 31 13:53:31.271 javascript execution failed (shell):1 TypeError: Property 'aut' of object admin is not a function db.aut('mongouser','mongopass') ^> db.aut('mongouser','mongopass')

哎呀 胖手指吧。 等等，我認為我發現了問題1

第1期

如果管理員用戶輸入的auth命令不是憑據，而不是憑據，那么實際的憑據將保留在Shell歷史記錄中，該歷史記錄將在各個會話之間持續存在。 任何其他用戶都可能會來查看Shell歷史記錄并獲取憑據。

另一方面，如果命令正確并且用戶名或密碼或兩者都不正確，或者確實進行了身份驗證嘗試，則該命令不會保留在歷史記錄中。 （可使用與Linux框相同的方式使用mongo shell的命令歷史記錄-使用向上箭頭）

> db.auth('mongouser','mongopass0') { ok: 0.0, errmsg: 'auth fails' } 0 > db.auth('mongouser0','mongopass0') { ok: 0.0, errmsg: 'auth fails' } 0 > db.auth('mongouser0','mongopass') { ok: 0.0, errmsg: 'auth fails' } 0

好。 讓我們針對管理員進行身份驗證并繼續。

> use admin switched to db admin > db.auth('mongouser','mongopass') 1

哎呀 我差點錯過那里。

第2期

在mongod實例重新啟動之前，任何用戶都可以…

> use admin switched to db admin > db.system.users.find() { '_id' : ObjectId('510a58c6de50e136190f9ed7'), 'user' : 'mongouser', 'readOnly' : false, 'pwd' : 'c49caa1cb6b287ff6b1deaeeb8f4d149' }

…獲取用戶名和哈希。 因此，既然我已經重新啟動了mongod實例，那么任何用戶都將必須針對admin進行身份驗證才能查看system.users的內容。 現在，繼續輸入不正確的憑據，我將發起字典攻擊，看看會發生什么。 噢親愛的。 發現了另一個問題。

問題＃3

沒有鎖定。 我寫了一個快速的技巧來連接到mongod實例，切換到admin并嘗試登錄。使用一個相當大的詞典（最后加上'mongopass'），我嘗試登錄了一百萬次。 這僅是一次粗略的單線程嘗試，大約需要17秒才能完成，但是它表明沒有帳戶鎖定。 我有信心，如果需要的話，我可以將多線程蠻力組合在一起。 我需要對此進行進一步研究，以查看是否可以配置任何強行強制/字典式攻擊警報，或者是否可以應用鎖定策略。 我還沒有準備好RTFM。 讓我們仔細看看system.users中的密碼格式。

c49caa1cb6b287ff6b1deaeeb8f4d149

在我看來，這就像MD5 。 讓我們看一下可在github上瀏覽的代碼。 哇！ 我很幸運。 db.js具有以下方法：

function _hashPassword(username, password) { return hex_md5(username + ':mongo:' + password); }

使用hex_md5然后在utils.cpp中引用native_hex_md5 ：

void installGlobalUtils( Scope& scope ) { scope.injectNative( 'hex_md5' , native_hex_md5 ); scope.injectNative( 'version' , native_version ); scope.injectNative( 'sleep' , native_sleep ); installBenchmarkSystem( scope ); }static BSONObj native_hex_md5( const BSONObj& args, void* data ) { uassert( 10261, 'hex_md5 takes a single string argument -- hex_md5(string)', args.nFields() == 1 && args.firstElement().type() == String ); const char * s = args.firstElement().valuestrsafe();md5digest d; md5_state_t st; md5_init(&st); md5_append( &st , (const md5_byte_t*)s , strlen( s ) ); md5_finish(&st, d);return BSON( '' << digestToString( d ) ); }

是時候快速回顧一下了。 萬一您錯過任何東西：

哈希算法為MD5 ; 我最不喜歡的哈希算法。

要散列的字符串格式為username + ':mongo:' + password ; 使用相同的“鹽”不是最佳選擇…

字符串:mongo:是全局的； 我不太確定為什么它會一直存在。

我認為這可能現在就足夠了，否則它將變成tl; dr，并且我可能會超出自我施加的時間限制。 回想我有關MongoDB的任何討論，相同的陳述總是出現在安全性的背景下。

默認情況下，身份驗證處于關閉狀態。

MongoDB始終旨在部署在受信任的環境中

我不得不說，即使啟用了身份驗證，我們仍然遇到一些棘手的問題。 此外，我認為不存在受信任的環境 。 此時，就安全性而言，是時候進行RTFM了。 我希望找到一個定義好的路線圖，以解決上述問題，或者已經可以采取一些緩解措施。 因此，在不久的將來會有一些 身份驗證功能。 看來新的身份驗證功能僅在MongoDB Subscriber Edition下可用，我不確定這意味著什么……我也遇到了這個已知問題 ，它構成了……的基礎。

問題＃4

如果用戶在多個數據庫中具有相同的密碼，則所有數據庫上的哈希將相同。 惡意用戶可能利用此漏洞使用不同用戶的憑據來訪問第二個數據庫。 [原文]讓我們分解一下。

“如果用戶在多個數據庫中具有相同的密碼，則所有數據庫上的哈希將相同。”

是。 正確。 相同的用戶名，相同的密碼和相同的“鹽”（即“：mongo：”字符串”）等于相同的哈希。 好，很酷，讓我們繼續前進。

“惡意用戶可能利用此漏洞使用不同用戶的憑據來訪問第二個數據庫。” [原文]

惡意用戶只有當在兩個數據庫中都擁有非只讀用戶時，才能利用此漏洞。

如果他們僅具有只讀訪問權限，則他們將無法列出system.users集合。 在這種情況下，他們將永遠不會首先看到不同數據庫之間的哈希值是相同的。 如果它們不是只讀的，則可以列出system.users集合，并使散列的密碼脫機破解。

總結來說，如果散列在數據庫之間不匹配，您將不得不進入破解領域：

用戶屬性將是相同的。 在具有用戶的不同數據庫上，不同用戶的幾率可能很高。

pwd屬性將是相同的。 不同用戶創建相同密碼的幾率很高。

“鹽”是相同的，因此在這里沒有實際意義。

因此，這里的問題是用戶（不是只讀用戶）可以提取給定數據庫的所有密碼哈希，然后將其脫機以進行破解。 惡意用戶已經具有用戶名和“鹽”，他們所需要尋找的只是密碼。

結論

第1期

這有點令人難過。 正確輸入命令后（忽略憑據是否正確），命令不會顯示在歷史記錄中。 如果未正確輸入命令，則很難知道要從命令歷史記錄中排除的內容。 我猜您可以追溯刪除導致身份驗證之前導致錯誤的命令（即無效命令）。 那不是解決方案……

第2期

可能存在一個論點，即在admin數據庫的system.users中創建了admin用戶后，應強制重新啟動。

問題＃3

不費吹灰之力。 我已經多次編寫了密碼策略（我過著什么樣的生活，是嗎？），帳戶鎖定是密碼101。

問題＃4

似乎為每個數據庫創建一個“鹽”（'：mongo：'）可以解決此問題。 看一下代碼，看起來實現是輕而易舉的事，是一次輕松快捷的勝利。 添加選項以手動設置它將會很盛大。 在幕后實施一個獨特的“鹽”，使用戶不必考慮它，同樣是宏偉的。 這樣，Nyetimber完成了，發布完成了。 我并不是說這篇文章中有什么新的或聰明的地方，這只是粗略的瀏覽。 我沒有去； 我提到的一切只是觀察。 我幾乎每天都安裝mongo，因為它是一個很棒的產品，但是我確實喜歡擁有平衡的視野并識別房間中的任何大象。 我會對任何反饋感興趣。

參考：來自我們的JCG合作伙伴 Jan Ettles的MongoDB身份驗證 ，位于ExceptionalExceptions例外博客。

翻譯自: https://www.javacodegeeks.com/2013/02/mongodb-authentication.html

總結

以上是生活随笔為你收集整理的MongoDB身份验证的全部內容，希望文章能夠幫你解決所遇到的問題。

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