題:
我可以隱藏數據庫中的哪個帳戶是admin帳戶,這樣攻擊者就不會知道首先破解哪個哈希?
Melkor
2017-05-02 13:45:36 UTC
view on stackexchange narkive permalink

說我有一個看起來像這樣的數據庫:

 名稱密碼哈希(bcrypt)狀態-------------------- -------------------------------------------------- ----------戴夫$ 2y $ 10SyyWTpNB.TyWd3nM hQ41frOtObcircAb3nJw1Cf9dC6CT7tVIEb6XS StandardSarah $ 2y $ 10 $ fUJrNA200sXgWUJAP7XEiuq4itHa43Y8QVIJ / YWscGVLV。 AdminMike $ 2y $ 10 $ 01jx7u7hnfKOzBYyjNWskOPQ23w1Cf1gNiv42wsKqXKOf8filzS02 Standard  

如果攻擊者獲得了對該數據庫的訪問權限,則他們會立即看到Sarah是管理員,並且很可能會著重於破壞該密碼,因此他們可以有更多的力量。我有什麼辦法可以以某種方式隱藏數據庫中是否有人是管理員,以使攻擊者不知道管理員是誰?我可以簡單地對值(標準值或admin)進行哈希處理,但這只會產生1比特的熵,並且我希望獲得更多的安全性。

攻擊者也可以直接查看最早的條目。在大多數係統中,這將是管理員帳戶:)
@Nat-他們如何僅使用哈希登錄?這對我來說沒有任何意義,儘管僅以每個用戶身份登錄才有意義,直到找到管理員為止。
在很久以前的宇宙中很長一段時間,我不得不實現類似的東西。我這樣做的方法是:哈希時在密碼前添加一個字母(實際上是多個字母,這是一個“組ID”),並具有身份驗證機制來嘗試所有組合。
這樣做會更簡單,並且最好是將1比特的熵添加到密碼(哈希)中,從而有效地使成功的蠻力攻擊的平均工作量增加一倍,而不是使攻擊者獲得1比特的偵察信息。同樣,對一百萬個散列進行暴力破解前圖像所需的時間不會比單個圖像所需的時間長(假設實際圖像前熵相等)。
普通用戶可以閱讀此列嗎?
@DavidFoerster這是一站式信息,因為可能有很多用戶。打破密碼散列與查找散列值的前映像不同,原因有兩個:“ 1.”大多數密碼的熵遠小於散列輸出的大小。“ 2.”這些哈希值看起來像是鹽化的。
@kasperd:您為密碼熵提出了一個很好的觀點,出於考慮簡潔和以下合理假設的考慮,我忽略了這一點:管理員密碼的熵要比普通帳戶密碼高得多,並且很可能是最後一個密碼。在典型的字典攻擊中發現的,該攻擊嘗試在隨機字符序列之前嘗試先使用短密碼,然後再使用長密碼,然後再嘗試使用常見單詞,然後嘗試使用不常見單詞。
@kasperd:關於信息的一點:可能有兩種以上的帳戶類型,但是在這種情況下,攻擊者只關心管理員與非管理員之間的二進制區別。
@DavidFoerster我的觀點是,對手從預先知道哪個用戶是管理員那裡獲得的信息,每個用戶接近1位,而不是總體上接近1位。對手所關心的只是管理員的密碼。如果數據庫中的所有密碼都同樣強大,那麼每個用戶只有1位知識就可以為對手提供很多幫助。但是,正如您所指出的那樣,管理員密碼的平均強度可能要強於其他密碼。這意味著知道哪些用戶是管理員,對攻擊者來說價值不菲。
當已經獲得系統訪問權限時,為什麼需要破解管理員密碼?
@JonasDralle攻擊者可能已從洩漏的備份中獲取了哈希。管理員可能對多個系統使用了相同的密碼。
也許不是混淆數據,而是執行基於證書的身份驗證。
如果攻擊者可以掃描您的數據庫,那麼您已經有比這大得多的問題了。
@JonasDralle TLS客戶端證書有其自身的問題。參見例如https://utcc.utoronto.ca/~cks/space/blog/tech/TLSClientCertificateWhen
基本上不是Kerberos嗎?:)
如果黑客可以訪問您的數據庫,為什麼不嘗試破解所有帳戶,然後將狀態更改為Admin?
@MatthewWhited:可以是只讀訪問。
給散列增加更多的熵也沒有什麼價值……密碼的真正問題是,人們使用容易猜測的密碼,或者如果被迫使用隨機(ish)密碼,則將其寫下來。如何實施兩因素身份驗證?攜帶智能手機的任何人均可免費使用Google Authenticator。甚至只是退休“ Dave”等,並堅持從16億個ID(合理記憶)的aannaann中隨機選擇。
九 答案:
Black Magic
2017-05-02 13:56:26 UTC
view on stackexchange narkive permalink

考慮到您從中得到的好處,我會說這有點麻煩。我認為,當攻擊者可以訪問數據庫時,您會遇到更大的問題。混淆用戶的管理員狀態只會使攻擊者花費一些額外時間,但是APT(高級持久威脅)可能不會因此而受阻。

究竟。混淆管理員身份就像試圖將您的物品用膠帶粘在地板上一樣無用,以防小偷無法得到它-他們仍然可以並且會做到這一點。您想阻止盜賊進入。
@JamesCameron,除非您的“物品”由10英寸的釘子組成。然後,我認為竊賊可能只是想知道您的問題是什麼...並報告您為瘋子。
@TheGreatDuck-而九英寸的釘子當然是完全合理的。
@TheGreatDuck:我告訴我的妻子,它們是10英寸的指甲,但實際上只有8.5英寸的指甲。
-1
@PieterGeerkens仍然過於樂觀...;)
schroeder
2017-05-02 14:08:08 UTC
view on stackexchange narkive permalink

通過混淆進行的安全性最多只能發揮有限的作用-要確定它是否合適,您需要了解要應對的威脅。如果威脅參與者可以直接讀取您的數據庫,那麼隱藏特定的存儲詳細信息有什麼好處?

如果混淆有 好處(請確保您能真正證明這一點),則可以採用針對威脅的混淆類型(加密值,離線數據源,哈希等)。

bdsl
2017-05-03 02:12:49 UTC
view on stackexchange narkive permalink

我同意Black Magic的做法,這也許不值得,但如果您願意,可以使用密鑰派生函數根據密碼創建加密密鑰,然後使用該密鑰對內容進行加密

可能,對於任何打開的用戶會話,狀態都必須保存在內存中,這樣攻擊者仍可能容易受到攻擊。

這意味著您將假設您不知道用戶密碼,則與攻擊者俱有相同的限制。您將無法從數據庫讀取狀態,如果要更改用戶狀態,則必須同時更改其密碼。

實際上,您可以在不知道密碼的情況下將狀態更改為非管理員-只需在字段中輸入一些隨機值,並依靠與“管理員”密文匹配的幾乎為零的概率即可。讀取它的代碼將必須容許意外的值。
或者,您可以擁有一個“ newStatus”數據庫列,並將其設置為純文本格式,然後在用戶登錄並清除加密狀態時將其清除。
這也意味著您無法擁有密碼恢復功能而不會丟失帳戶的狀態。
好點@MichaelKjörling可能會破壞交易。
phyrfox
2017-05-03 00:34:18 UTC
view on stackexchange narkive permalink

實際上,許多現代系統確實將用戶的登錄名(他們如何進行身份驗證)與“個人資料”(他們擁有的權限)分開,實現為兩個或多個離散系統。您的登錄服務器可能只有一個GUID,一個哈希用戶名和一個密碼。成功登錄後,將會話轉移到應用程序服務器。只要您的應用程序服務器沒有受到破壞,登錄數據庫即使被轉儲也無濟於事。

作為附加的步驟,您還可以使用來自登錄服務器的密鑰(存儲的用戶名)加密用戶數據作為會話的一部分),也使應用服務器更加安全。通常,兩個系統比一個系統更難被擊敗。但是,如果您不願意設置兩個服務器(或群集),而這聽起來似乎工作量太大,那麼無論如何,您最好還是使用當前的設計。僅僅知道要定位哪個帳戶並不會使工作變得容易。如果攻擊者可以破解,那麼他們可以使用並行計算破解所有漏洞。

satibel
2017-05-04 11:53:13 UTC
view on stackexchange narkive permalink

PlasmaHH的建議是:“在散列時給密碼加上一個字母(實際上是多個字母,它是一個“組ID”),並具有驗證機制來嘗試所有組合。”

儘管從某種程度上講是安全性,但需要與諸如

  • bcrypt的強大工作因素
  • 的優秀實踐配對。強大的密碼
  • 首先可以防止攻擊者擁有數據庫副本

這是一種很好的方法,可以使攻擊者充分放慢速度,以便

破解一個不平凡的密碼(假設您使用了強大的工作因素)可能需要幾天到幾個月的時間,因此可以這樣做,但是如果不這樣做,不知道哪個帳戶值得黑客入侵,這使他們不得不入侵每個帳戶。

因此,除非他們很幸運,或者您將管理員帳戶命名為“ admin”,否則他們將不得不嘗試多個帳戶,使他們的成本至少為數量級更大的範圍,使攻擊者要么等待更多,購買更多電力,要么放棄。

總而言之,它並非一文不值,因為它是一種廉價的威懾手段,不會打擾用戶。

請注意,如果您暗示有人是管理員,例如他們編輯的某人的帖子(如果只有管理員可以這樣做),則在數據庫中屏蔽其狀態是沒有用的。

就像其他人提到的那樣,這有點像阻止您在不更改用戶密碼或至少不要求其密碼的情況下使用戶成為管理員。

如果可以的話,要求對管理員進行兩因素身份驗證可能會更好保護管理員帳戶的方法。

sebastian nielsen
2017-05-04 19:00:53 UTC
view on stackexchange narkive permalink

是的。只需將管理員狀態添加為密碼的一部分。

例如:HereIsMe!65371 = adminHereIsMe!65370 =常規

然後在登錄時先嘗試常規然後是管理員,例如:

  if(sha512($ password。“ 0”)eq $ hash){blabla用戶函數} else {if(sha512($ password。“ 1”)eq $ hash){blabla管理功能}其他{顯示不正確的密碼消息}}  

重要提示:請確保您確保其他人無法編輯自己密碼的最後一個字符。例如,確保註冊表格,忘記密碼表格和更改密碼表格,請始終根據其真實狀態在密碼末尾附加0或1。將狀態存儲在服務器端會話中,最好使用客戶端加密-會話cookie。

這使得在沒有成功破解密碼的情況下幾乎不可能推斷出管理員狀態。

知道方案並尋找1會破壞您的系統-如果您有一個單獨的表列出管理員是誰,為什麼不使用它代替管理密碼呢?然後,如果您有此表,如何保護它不與問題中提到的表一起閱讀?
而且,這與satibel的答案非常相似
怎麼樣?1是密碼的哈希部分。是的,您可以告訴您的哈希解密器在密碼後附加1,但是您仍然不知道哪個帳戶是admin,因此您仍然必須破解所有帳戶。
如果我以管理員身份登錄,系統在散列之前如何知道在提供的密碼後附加1?
-1
@schroeder如果您檢查示例代碼,則會看到它將首先嘗試以普通用戶身份登錄,如果哈希不匹配,它將測試admin。訣竅是無法在不知道密碼的情況下事先知道哪個用戶是admin。
@Voo是的,是的,您必須對用戶重置管理員權限才能對用戶執行“忘記密碼”。但是,這實際上是一項很好的安全功能,因為如果某些黑客(例如通過入侵電子郵件帳戶)入侵了重置密碼功能,則管理員權限仍然是安全的。更改密碼時,會話已經知道登錄的用戶是admin還是user。
因此,沒有必要為用戶添加0,您只需為管理員添加1,但是系統如何知道用戶應該首先添加此額外的位?為什麼不只是將管理員哈希硬編碼為您的示例代碼?您的建議似乎無法維持,而且肯定無法擴展。
@schroeder必需將0添加到用戶,否則您將冒著用戶在其密碼中添加1並成為管理員的風險。通過對管理員哈希進行硬編碼,您可以通過查看代碼+ db來推斷管理員。但是根據我的想法,即使擁有訪問權限,您也無法推斷出誰是管理員。您可以嘗試破解密碼,並檢查0或1是否與哈希匹配。
@schroeder什麼是解決方案不可擴展的?您可以將其擴展到任意數量的權限,甚至允許位標誌。它相當脆弱並且有一些缺點,但是可以解決給定的問題。
像這樣的解決方案的另一個問題是,很難為高級管理員實現一個接口,以撤消其他有問題的用戶的管理狀態,因為任何理智的實施都只會將管理狀態本身存儲在會話數據中。登錄,因此無法檢查每個相關請求的角色,因此要撤消管理員訪問權限,必須強行刪除登錄會話數據,以便用戶必須再次登錄。
這是唯一可以正確回答問題的答案。
cybernard
2017-05-04 06:19:08 UTC
view on stackexchange narkive permalink

如果您的數據庫支持它,則設置LDAP或類似的身份驗證服務器,然後憑據將不會存儲在本地。

問題是關於隱藏授權,而不是身份驗證-如果無法正確實施,則使該消息可從遠程源查詢變得更糟(授權信息僅在成功身份驗證後才可訪問!)
@rackandboneman有問題的服務器在服務器上將沒有憑證,因此它們將被隱藏。如果您擁有自己的網絡,並且使身份驗證服務器對Internet可見,那麼您應該被黑客入侵。顯然,您必須使用2048位或更多的TLS,等等等等。
S.C.
2017-05-05 09:50:49 UTC
view on stackexchange narkive permalink

這裡有一些有趣的技術建議,但是需要指出的是,即使您完美地實現了這些建議,由於以下原因,這種方法在入侵時也不會給您帶來任何好處:

  • 如果某人具有數據庫訪問權限(通過sql注入或類似方法),則可以肯定的是,由於大多數數據庫管理系統,他們可以在運行數據庫服務的任何用戶的許可下,在服務器上做任何想要的事情提供用於操作文件並在其主機上運行進程的功能。這意味著入侵者可以修改您的網頁或服務器端處理,以在登錄期間捕獲純文本密碼,並非常快速地為活動用戶獲取未加密的密碼。我假設您的管理員帳戶是活躍用戶。
  • 如果某人獲得了對您的密碼哈希的訪問權限,則他們可能不會撥入他們應該首先嘗試破解的密碼。他們只會運行一個批量解密器一次處理所有這些解密器,並且每次通過它都會檢查他們正在處理的表中的所有哈希。
  • 即使您將管理員密碼哈希保留在其中如果一個單獨的表或完全在數據庫外部,則特權較低的帳戶的入侵很可能導致特權升級,只要入侵未被發現,因為入侵者將能夠模擬受信任的用戶以獲取更多信息的訪問權限(通過使用版主帳戶與管理員進行對話,並開始竊取Cookie或進行其他惡意活動。)
  • 如果您的網站具有社交功能,則很可能已經公開了其他方法來識別管理用戶。
Raphael Marco
2017-05-02 20:26:28 UTC
view on stackexchange narkive permalink

如果攻擊者獲得了對數據庫的訪問權限,則他們可以製作自己的bcrypt哈希並替換數據庫中的那個。無需破解哈希。

如果他們只有讀取權限,則不會,例如數據轉儲之類的東西。
同樣,即使他們確實具有寫訪問權,也無法幫助他們將隨機的bcrypt哈希插入數據庫。他們必須了解授權系統的密碼才能使其接受哈希,如果他們能夠做到,那麼他們可以更加輕鬆地解密現有哈希。
不回答問題。即使您的建議是正確的,攻擊者也必須知道要替換哪一個。
@KernelStearns甚至我也知道原始方案的密碼學。您只需要查看哈希即可。它是bcrypt,成本為10。
-1
僅當攻擊者想要大聲宣布自己時,@AjayBrahmakshatriya。如果攻擊者想提高戰術水平(安靜),那麼知道要鎖定哪個帳戶就很重要。因此,不,此答案“繞過並消除”了問題,但沒有回答。
@Schroeder我的意思是,他可以一個接一個地替換(如果不是管理員則可以替換)。這比嘗試逐個破解每個散列要容易得多。因此,如果攻擊者對此表具有寫訪問權,則隱藏管理員狀態實際上是行不通的。
對於具有數千名用戶的系統,@AjayBrahmakshatriya的工作量很大。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...