mongodb身份驗證

我最近更新了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身份驗證 ，位于Exceptionalexception exceptions博客上。

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

mongodb身份驗證

總結

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

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