題:
如果僅存儲哈希值的公司的密碼如何被盜?
W2a
2019-03-17 00:44:39 UTC
view on stackexchange narkive permalink

我在任何地方看到的都是服務器以散列形式存儲密碼,但是您卻得到了有關黑客從大公司竊取密碼的重大新聞。我想念什麼?

也可以通過將密碼竊聽未加密的密碼來竊取密碼。而且至少在一點上它們是未加密的,即在用戶的鍵盤上。
_“我到處都說服務器以散列形式存儲密碼” _不,它說服務器_應該_以散列形式存儲密碼!
如果您的密碼是“ 123abc”,則一旦數據庫被盜,任何哈希,加鹽或加粗字符都不會確保您的帳戶安全。
您還需要對人們進行安全性教育。如果您的密碼具有足夠的熵,則可以使用哈希和鹽,但是您的員工會在便利貼上寫下密碼並將其保留,或者僅將其交給“確實需要服務器上的文件”的同事,您就會遇到問題。查找“社會工程學”
我在一個食品櫃檯工作了足夠長的時間,以至於可以使用六個組合,如果您告訴我客戶的總數,我可以告訴您他們訂購了什麼,而沒有收據或不知道他們的特定訂單。
相關xkcd:https://xkcd.com/1286/
幾乎所有的違規行為都始於社會工程或找到一個弱密碼,然後從這一點開始潛入系統。
因為一些公司的行為像流氓一樣白痴:https://krebsonsecurity.com/2019/03/facebook-stored-hundreds-of-millions-of-user-passwords-in-plain-text-for-years/
八 答案:
user10216038
2019-03-17 04:42:10 UTC
view on stackexchange narkive permalink

除了讓數據庫或文件首先被盜之外,還有兩個常見的失敗。

不幸的是,根據所有安全建議,許多系統仍然存儲純文本密碼。

散列密碼在技術上是不可逆的,但是正如其他人所指出的那樣,可以對數百萬個密碼猜測進行散列,然後僅查找匹配項。實際上,通常會發生的情況是,預先計算的密碼和哈希表(彩虹表)可用並用於查找匹配項。一個好的彩虹表可以在每密碼散列的幾分之一秒內支持很高的百分比匹配。

使用密碼的額外非秘密擴展)阻止使用預先計算的彩虹表。

大多數入侵者都依賴彩虹表。計算自己的哈希集當然是可能的,但是這非常耗時(例如數月或更長時間),因此通常是原始哈希很容易受到攻擊。散列的散列哈希可以使暴力破解從幾個月過渡到幾年甚至更長。大多數機構根本沒有實施這種級別的安全性。

我不同意您的說法“大多數妥協者都依賴彩虹表”。儘管它們在某些情況下很有用,但有證據表明,密碼破解仍然很受歡迎,因為無論鹽化,不同的哈希類型和迭代哈希如何,密碼破解仍然有用。
鹽不會阻止使用預先計算的彩虹表或停止彩虹表。他們只是使難度增加了幾個數量級。請記住,隨機數生成器有可能(但不太可能我們可以安全地假裝它永遠不會發生),可能會在第一次嘗試時就猜出您的密碼。
*“散列的密碼在技術上是不可逆的” * ...是真實的但具有誤導性,因為您不需要將其逆轉,因此只需要散列到同一事物上的原像即可。
從技術上講,散列密碼都是可預映像的(假設它們使用了合理的散列算法)。只是大多數密碼很容易猜到。
僅供參考,該短語是“在上方”,而不是“在上方”。如果這是一個簡單的錯字,請忽略我。
@Mehrdad但這就是鹽醃如此重要的另一個原因-即使您在哈希表上發現了衝突(MD5在今天很容易發生碰撞,並且仍被廣泛使用),該衝突*在其他系統上將無法使用。
Rainbow表對於長而低熵的密碼(用33t格式的電影引號等)也無效,而最好的破解工具卻是有效的。它們破壞了舊的LanMan密碼,但我認為它們並未被廣泛用於其他任何用途。
“ ...許多系統仍存儲純文本密碼。”對。大約2年前,我們收到了一個數據庫的副本,該數據庫將用於替代數據庫。(我們將遷移數據。)無論是誰將其轉儲並發送給我們,都不會費心從中清除所有純文本密碼,這意味著我可以在一個現成的政府系統中假扮我想要的任何人。
網站plaintextoffenders.com維護著[公司列表](https://github.com/plaintextoffenders/plaintextoffenders/blob/master/offenders.csv),用於以純文本或其他可恢復格式存儲密碼。該列表目前有5,000多個條目。
-1
@DoktorJ這也是一個安全問題。從技術上講,其中一些可能正確地存儲了密碼,但是它們會生成一個密碼,並在存儲之前通過電子郵件將其發送給您。但是,這樣做本身就是一種處理密碼的糟糕方法。該網站旨在揭露使用這兩種做法的公司,因此沒有區別。要點是,他們通過可怕的安全做法以明文形式公開密碼。
@jpmc26我現在可以致電我的ISP,並要求他們恢復我的帳戶。他們會通過電話告訴我當前的用戶名和密碼。
如果它們是在不加鹽的情況下進行哈希運算,那麼即使沒有彩虹表,某些密碼也會變得容易猜到。每個使用相同密碼的人都被映射到相同的哈希,然後通過頻率分析可以輕鬆找出誰在使用“ password123”等。
Dam30n
2019-03-17 01:28:32 UTC
view on stackexchange narkive permalink

當您聽到密碼被盜時,有時公司會報告該密碼,即使只是散列的密碼被盜了。這樣,您就可以在它們損壞的情況下採取措施。不幸的是,仍然有一些公司錯誤地存儲了密碼。例如,如果您搜索rockyou密碼違規,您會發現它們以明文形式存儲了密碼,這意味著它們在被盜後便立即受到了威脅。在其他情況下(例如Adobe密碼洩露),存在將加密密碼存儲在其數據庫中的處理不當的情況。其他時候,公司在其密碼上使用散列,但使用不安全的散列算法,或者它們未正確對密碼加鹽。簡而言之,如果公司遵循推薦的密碼存儲方法,則理論上密碼應採用散列形式,但安全,但是好的公司仍會告知其客戶違規行為。但是,有很多例子表明公司沒有正確存儲密碼,導緻密碼很快被破解。

即使您做對了所有事情,竊取所有哈希密碼(大概還有用戶名或電子郵件)也可以使對密碼的其他攻擊變得更加容易-尤其是採用MD5這樣的舊機制,無論是否加鹽。而且考慮到大多數人在多個站點上使用相同的密碼,並且密碼仍然經常不夠安全...沒錯,如果您使用帶有適當鹽分的良好的慢速散列,則影響非常小。
Future Security
2019-03-17 02:52:58 UTC
view on stackexchange narkive permalink

您對大量可能的密碼進行了哈希處理 * sup>,然後檢查每個輸出是否與被盜密碼數據庫中的任何哈希值匹配。蠻力破解是可行的,因為人們 不要 通常會選擇高度不可預測的密碼。

當密碼數據庫被盜時,被盜材料將包含所有信息進行離線破解很有必要。 (這只是一個猜測和檢查過程。其他方法可能使用不太安全的哈希或密碼存儲方法。)

*如果使用了鹽,那麼餅乾也必須考慮那些鹽。如果每個帳戶使用唯一的鹽,那麼破解者就不能簡單地通過對每個候選密碼進行一次哈希處理來鎖定所有人。如果將多個帳戶作為目標,則每種鹽都必須對您想要嘗試的密碼進行一次哈希處理。如果密碼哈希值未加鹽或全部使用相同的鹽值,則進行非針對性的攻擊要容易得多;您只需要對候選密碼進行一次哈希處理即可找出擁有該密碼的用戶的完整列表。鹽還使嘗試使用哈希的預先計算來節省破解工作變得毫無用處。如果僅針對一個帳戶,則鹽不會減少需要評估的哈希數。除了這些細微差別外,密碼破解的基礎仍然是猜測和檢查過程。 sup> sub>


使用具有足夠不可預測輸入足以使其無法恢復密碼。 (一個不人道的強密碼。)

但是,在現實世界中,大多數人都不會這樣做,一個被盜的哈希數據庫可能會像大量未加密密碼的列表一樣令人擔憂。一個典型的網站。

如果密碼破解者發現其哈希值與數據庫中存儲的哈希值匹配的候選密碼,則他將恢復原始(弱)密碼。


或者,如果散列函數不耐原像(包括散列的輸出太短時),則猜測檢查過程可能會產生誤報。 (替代密碼與原始密碼不同。)

公司中有數據洩露行為的用戶帳戶仍然易受攻擊,因為這些密碼將解鎖用戶的帳戶甚至(如果它們與原始密碼不同)。 (服務器無法確定它是否是原始密碼。在這種情況下,哈希仍與被盜數據庫中的密碼匹配。)

當然,不要故意使用不安全的哈希函數。 。仍然可以推斷出原始密碼或縮小可能性的數量。仍然會使在其他網站上重複使用密碼的用戶更容易受到攻擊。


還有其他一些可以使密碼被盜的方法,而這並非源於密碼哈希數據庫的副本被洩露。可以記錄純文本登錄信息。 (例如,通過黑客入侵和重寫服務器代碼,或利用客戶端錯誤,觀察未加密/解密的網絡流量。)然後可以提取該日誌。

當然,有些公司可能一開始就沒有使用安全的密碼驗證方案,或者可能會通過錯誤 1 2。 sup>

儘管對大規模密碼洩露的某些情況有其他解釋,但從密碼哈希中恢復明文密碼是常見且有效的。但是,它並不是很有效,因為每次大型數據庫洩漏中的哈希值都將被100%恢復。

如果使用加密哈希功能處理密碼,則密碼強度極高的用戶不必像普通用戶那樣擔心。 (但是大多數人過分估計了密碼強度和他們自己的聰明才智。)在花費大量資源來破解99%的哈希之後,破解最後的1%可能不值得或不切實際。但是,如果不對密碼進行散列,則強密碼就不好了。

開發人員應使用密碼擴展算法。這些算法只是試圖使密碼哈希變得更加昂貴。 (對於合法用戶和密碼破解者。) Argon2當前是最佳的密碼擴展算法,尤其是在Intel / ARM CPU上。尤其是Argon2可以大大減少散列中將被破解的部分。 (弱密碼仍然可以破解。)

“您對大量密碼進行哈希處理,然後檢查輸出是否與任何存儲的哈希匹配。”鹽醃可以解決這個問題。
@Taemyr對我來說,這尚不清楚,這意味著預計算的哈希值,儘管可能會更清晰一些。鹽析只會使字典攻擊在計算上更加困難,並且無法進行預計算。
@Taemyr除非他們設法成功地破壞了您的系統以竊取數據庫,否則他們也可能設法竊取了您的鹽。
我不想通過加鹽來使事情進一步複雜化,但是由於問題越來越多,在這一點上我也希望如此。理想情況下,我將以更簡單,更有條理的格式說明相同的信息...網絡傾向於將使用鹽的原因簡化為“更安全”或“完全安全”。他們使畜群更安全,但使個體更安全。使用查找表,鹽可以完全有效地防止“反轉”哈希。他們根本沒有採取任何行動來減慢定向攻擊的速度。但是任何不使用長時間隨機的獨特鹽的人都犯了一個嚴重的錯誤。另外,使用Argon2
jcaron
2019-03-18 19:22:11 UTC
view on stackexchange narkive permalink

許多可能性:

  1. 即使密碼應該在存儲前進行散列,但並非總是如此。可悲的是,即使在今天,仍然有很多以明文形式存儲的密碼。竊取數據庫,獲取所有密碼。

  2. 密碼可以存儲在其他地方。例如,密碼可以包含在日誌中。竊取日誌,獲取在這些日誌中使用的所有密碼。

  3. 密碼可能會散列但不會加鹽。因此,您將基於各種密碼構建密碼列表->哈希組合。您反轉此表,使其成為哈希->密碼(查找表)。獲取數據庫,將散列轉換為密碼,獲取大量密碼。

  4. 密碼經過哈希處理和加鹽處理。但是許多用戶使用非常弱的密碼(123456,密碼,letmein,qwerty ...)。嘗試針對那些哈希密碼列表。獲取數據庫,對散列進行字典攻擊,獲取大量密碼。

  5. 上一個版本的變化,而不是預先確定的列表密碼,請根據您擁有的有關用戶的其他信息嘗試使用密碼(用戶名,名字,姓氏,生日,電子郵件...)。

  6. 還有另一種變化,因為許多用戶重複使用相同的密碼:對於從其他漏洞中恢復的相同電子郵件/用戶名,嘗試輸入 密碼

  7. 還有另一種變化,當有一個強有力的密碼策略需要定期更改密碼時:如果您有該用戶的先前密碼,請嘗試更改最終數字:如果用戶一次有密碼“ joe12”,請嘗試使用joe13,joe14,joe15...。如果您具有初始密碼的有效日期並且知道密碼更改間隔,則可以很快。

  8. 密碼經過哈希處理和加鹽處理,但使用弱(快速)哈希。與#4-7相同,但是您可以更快地進行更多嘗試,因此您可以嘗試更大的詞典,甚至可以系統地嘗試所有組合(強力攻擊)。

  9. 客戶端和服務器之間的通信容易受到中間人(MITM)攻擊。

  10. 您將在途中捕獲密碼。您執行社會工程。 “您好,這是IT部門,您的帳戶有問題,我們需要重設一些密碼,您能給我您的密碼嗎?”?

  11. 大規模的社會工程學,又稱為網絡釣魚,您會驚奇地知道這種方法的工作頻率。登錄到將捕獲所有這些密碼的網站。

  12. 破解該網站,然後對其進行修改,以使其將接收到的所有密碼發送到遠程服務器 (或將它們記錄到以後要檢索的文件中)。

  13. Ditto,但可以修改客戶端代碼來實現。可能就像存儲的XSS 黑客一樣簡單。

  14. 上述內容的一種變化:鍵盤記錄器

  15. ol>

    可能還有很多其他方法,但這使您了解了恢復大量密碼的難易程度。

對我來說,第七才是天才
這是迄今為止最完整,最準確的答案。
Tipping44
2019-03-17 02:21:20 UTC
view on stackexchange narkive permalink

由於我們沒有在討論密碼是如何被盜的,更不用說後果了,因此,我將避免公司應採取的許多措施來防止這些數據洩露。

如果您創建一個網站並管理數據庫,則我們有責任有效地存儲該信息。如果沒有,那麼在發生數據洩露時,攻擊者可以視情況以純文本形式查看密碼(取決於密碼的存儲方式)。

在簡而言之,您永遠都不會希望這種情況發生! -密碼破解是非常普遍和真實的事情,僅因為密碼被散列並不能以任何方式使它們變得安全。

比方說一家公司有1000個客戶密碼,所有這些密碼都是經過哈希處理的。

比方說,其中600個客戶的密碼為8個字符長的密碼,這些密碼被破解的可能性在開始的5分鐘內(慷慨)很高。

“ 5分鐘?!但是他們被散列了!”...。

是的,但是那600個客戶的密碼仍然很差,而且散列算法也很差。

為了簡化說明,沒有太多細節。密碼破解的工作原理是簡單地將哈希與單詞的字典文件匹配,遍歷每個單詞以查看其哈希是否與從這600個客戶那裡獲得的哈希匹配,例如,您的密碼可能是:

密碼:安全性

MD5散列:2FAE32629D4EF4FC6341F1751B405E45

然後我只是針對這些散列運行一些有利的黑客工具來“破解”

如果您想自己存儲密碼,應避免使用MD5,以上純粹是出於示例目的。取而代之的是,研究更強大的哈希算法類型,這會使攻擊者更難於成功利用他們所竊取的密碼。

簡短答案;哈希或您存儲密碼的任何格式都不會影響黑客竊取密碼的能力。由於各種不同的漏洞,它們被盜了。有多種攻擊可幫助您獲取密碼(無論是否經過加密)。

只需注意,使用“安全”等弱密碼,您甚至不需要破解工具,您只需使用Google 2FAE32629D4EF4FC6341F1751B405E45
更重要的是,現在本文已被索引!
只是要注意:儘管完全不應該優先使用MD5而不是諸如SHA2或SHA3之類的較新算法,但對於密碼哈希而言,它們卻幾乎一樣糟糕,因為它們太快了。請使用具有適當安全性參數的迭代哈希(例如PBKDF2,bcrypt或scrypt)。
Steve
2019-03-19 21:33:33 UTC
view on stackexchange narkive permalink

尤其重要的一點是,當密碼數據庫是安全的並且只能由合法服務訪問時,嘗試訪問帳戶的人只能通過合法服務單獨進行嘗試。可以注意到重複嘗試失敗的情況,提供了自動警報,並採取了適當的措施來限制來自同一來源的進一步登錄嘗試。

一旦密碼數據庫被盜,並且已知哈希算法的詳細信息,擁有被盜密碼數據庫的人員可以嘗試對他們的數據庫副本嘗試數百萬或數十億個密碼,而不會給任何人造成任何進一步的警報,當他們找到一個可用於其脫機副本的密碼時,他們才這樣做嘗試訪問冒充該服務的用戶之一(也許是您!)的合法服務。

很大一部分用戶的密碼很可能是攻擊者嘗試使用的前十億個密碼,因此攻擊者可以訪問相當大部分的帳戶,只需要很短的時間。

那些確實擁有強密碼的用戶應該能夠安全地忽略只有散列密碼的妥協被洩漏d,但是實際上許多用戶沒有足夠強大的密碼來抵抗這種脫機攻擊,只是那些對站點自動密碼強度檢查器似乎足夠強大的用戶,通常更關注確保帳戶具有足夠的強度以抵抗在線攻擊違反合法服務。

Sevron
2019-03-17 15:55:13 UTC
view on stackexchange narkive permalink

對於Web應用程序,還應考慮以下攻擊媒介:

如果攻擊者可以修改前端代碼,則可以使用一個小的腳本來“嗅探”一段明文密碼。

p>

如果可以從後端注入腳本,則可以將其設置為僅向來自某些國家/地區的訪問者顯示,以更好地防止在與應用程序所在國家/地區運行的惡意前端代碼更改檢測自動化。運行。

supercat
2019-03-19 01:31:28 UTC
view on stackexchange narkive permalink

雖然希望以散列形式存儲密碼,但也會帶來一些困難。如果一個實體有必要代表用戶向另一個實體發出請求,而第二個實體需要提交純文本密碼以進行驗證,則第一個實體將需要以一種可轉換為以下形式的形式保存用戶的密碼:

為此,公司可能會將密碼存儲在各種硬件安全模塊中,這些模塊會審核所有嘗試從中檢索密碼的嘗試。這種方法減輕了明文密碼存儲所涉及的許多危險。它無法緩解所有危險,但是如果某個實體有權代表用戶訪問外部實體,並且該外部實體不接受用戶密碼以外的任何東西作為該授權的證據,不管第一個實體試圖做什麼,與純文本密碼相關的某些危險都是不可避免的。

我不清楚在什麼情況下,這樣的第二個實體會允許第一個實體模擬大量用戶,並且無法為該第一個實體提供適當的身份驗證機制。在許多情況下,向此類第一實體提供其密碼以訪問第二實體的用戶將違反第二實體的服務條款。有沒有這樣的第一實體/第二實體的具體示例?
@Steve:我正在考慮使用諸如自動化工具之類的工具來執行某些操作,例如在特定時間發布消息,檢查一項服務中的消息並將通知(和/或消息內容)轉發到另一項服務等。讓一項服務支持某種形式的代理憑據可以與自動化服務共享而不必共享主要證書的方法會更好,但是這需要主要服務提供者的合作。另一個相關情況是設施需要在存儲密碼的服務之間同步密碼。
如果公司X繼承/獲取一個系統X,所有X的用戶都應使用其當前憑據自動接收該系統,但是Y的身份驗證機制以不同的方式哈希密碼,並且X不能更改它,那麼X應該如何在沒有Y密碼的情況下在Y上創建帳戶存放在某個地方?如果X使用安全的硬件存儲模塊,而沒有八個私鑰中的至少五個,則這些安全硬件存儲模塊將無法解密用戶密碼,每個私鑰僅存在於Universe的一個位置,並且這些私鑰的持有者都將監督所有用完了,...
...那麼儘管可以在適當的情況下對數據庫進行解密,但仍然可以維護密碼的安全性。請注意,在某些情況下,公司需要不適當的憑據暴露,例如衛星網絡,該網絡要求用戶提供衛星提供商的憑據才能訪問流內容(大概是這樣,網絡可以使用客戶的帳戶工具來確認客戶實際上已經訂閱了,但是衛星提供商沒有理由要這樣做!)。


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