題:
對於使用“需要幾個世紀才能破解”的密碼感到困惑
Batman
2018-05-05 00:55:44 UTC
view on stackexchange narkive permalink

我說的是這個密碼- 23 ## 24 $$ 25 %% 26 以及類似的由特殊字符組成的相似字符,這些特殊字符以一種模式出現,這幾天用戶經常使用。 p>

在工作中(金融公司),我正在創建一個不允許用戶選擇的錯誤密碼列表,其中涉及某些週期或模式,而上述種類表現出包含連續數字的特徵,該數字包含特殊字符(重複一定的次數,這裡兩次。)

出於好奇,我在一個非常知名的網站(在其登錄頁面上)上對此進行了檢查,並指出這將需要幾個世紀的時間。 >

列表中的其他一些示例可能需要幾年的時間才能破解,但非常脆弱:

1!2 @ 3#4 $ 5%6 ^ >> 2 @ 3#4 $ 5%6 ^ 7& a!b @ c#d $ e%f ^

現在,我對列表感到困惑,應該我將這些特殊類型的密碼標記為易受攻擊,即使用戶需要很長時間才能將其禁止使用,

注1-我們正在考慮這些易受攻擊的用戶,因為許多用戶(因此,多個相似的密碼)都遵循這種趨勢來輕鬆記住事情。
注2-我們感到困惑,因為安全性人們都在增加熵,而他們卻忽略了數據庫中類似哈希值的有序性。
在我們之間劃定一條線(定義允許或不允許使用的密碼)之間,人們之間產生了摩擦。

編輯:

  • 我正在談論的這個網站,但沒有名字,我測試過的密碼很漂亮每個道德/不道德的黑客都非常了解,Stack Exchange上的幾乎每個用戶以及許多大/小公司(因為他們使用其服務)都是眾所周知的。

  • 我們不以純文本格式存儲密碼。我們使用一種不錯的而非自釀的哈希算法。
    一次事件導致我們查看了我們的密碼政策,並在另一台計算機上創建了一個單獨的數據庫 db-2 ,其中我們存儲了simple_hashed_newly_created用戶的密碼(不加鹽,不包含任何內容,僅包含hashed_pa​​ssword),而未存儲who_created, when_created的詳細信息。我們僅在短期內這樣做。任何密碼更改也都進入該數據庫。同時,在我們的原始數據庫 db-1 中放置了secure_salted_pa​​sswords。
    我們也按照一種模式,繼續創建了哈希易受攻擊密碼的列表 L ,我們被留下了。當我們匹配 L & db-2 時感到很有趣-我們看到了多組相似的密碼,具有特定的模式。後來從系統中刪除了 L db-2

  • db-2 被保存在高度安全的機器上並且很安全,因此在此不會透露確切的詳細信息。我們知道,即使是氣隙或電插座也不是安全的。 db-2 L 均被銷毀。

  • 不用擔心這裡發布的密碼,因為我們已經進行了操作進行了一次小型實驗,並設置了所有這些特定的用戶名來重置密碼(當然,新密碼與舊密碼不同)。這就是原因,我來這裡發布的樣本很少。
    而且,我之前也曾在這裡發表評論,我從生成器的邏輯中發布了密碼樣本,該邏輯創建了非常龐大的哈希密碼列表,該列表可能是也可能不是在 db-2 中。再一次,由於所有這些用戶都有一個新密碼,因此不用擔心,一切都是安全的。

  • 由於我知道生成器的工作原理,因此我在網站上,我們對於允許或禁止使用哪些標準以及哪個標準感到困惑。

非常感謝您的回答,感謝我。根據回答,我們暫時推遲了對密碼選擇的任何限制。

這些密碼可能要花幾個世紀才能破解(bruteforce),但無需花太多時間去猜測。
網站不應該說“這需要幾個世紀才能打破”。他們應該說:“這將花費**個世紀的時間”。而且它們比您的基本攻擊者都愚蠢得多。
考慮(也)使用:https://haveibeenpwned.com/Passwords
無論如何:您怎麼知道您的用戶經常使用那種密碼?您是將密碼保留為純文本形式還是加密形式而不是哈希形式?還是您正確實施了密碼更改過程中執行的某些檢查,以查看所選密碼是否符合這些類別?
密碼*熵*(僅針對長度或複雜性)是您要這些網站確定的內容,對於它們來說,要精確地進行工作幾乎是不可能的。
順便說一句,當您在上述網站上嘗試輸入密碼時,它們很可能會將它們添加到字典中。
提到“數據庫中的類似哈希”是什麼意思?您碰巧多次具有相同的哈希值?
注意不要[對人類難於使用密碼,但容易使計算機猜到](https://xkcd.com/936/)
我不明白您為什麼決定在事件發生後開始維護未加鹽密碼哈希的列表。保持這種狀態似乎是在自找麻煩。您是否考慮過多因素身份驗證?
@ZachLipton:該無鹽密碼列表僅維護了很短的時間,並在另一台機器上不斷地移至`db-2',因為我們想在推出新指南之前確認自己的疑問。從來沒有人看到過純文本密碼,易受攻擊的密碼列表也被散列了,它也不是純文本列表。我們使用了一個生成器來生成這些圖案化密碼的哈希。因為我們知道該生成器中的邏輯,所以我發布了一些可能/可能不在db-2中的模式。一旦我們匹配了db-2和清單L,就會刪除它們。
我希望您已經在網上發布這些密碼,也不要再使用這些密碼或同一模式產生的任何密碼。未加鹽的數據庫聽起來也有安全隱患。
@JOW同意。我手動“破解”的第一個密碼是1990年代初。我查找了一個我知道有很多語音郵件線路的公司的電話號碼,並在電話上輸入了以下號碼:2580456。我怎麼這麼容易進入?看電話墊:我只是在中間用數字下線,然後在中間用相同的數字。一些技術人員使用(容易使用嗎?)設置的簡單/惰性密碼。
即使對於我的老Radeon 5870來說,14個字符也不是多少。“世紀”部分是什麼?
“他們所忽略的是數據庫中相似哈希的有序性增加了。對於安全性哈希函數,[Continuity](https://en.wikipedia.org/wiki/Hash_function#Continuity)並不是令人滿意的質量。您通常想要一種具有[雪崩效果](https://en.wikipedia.org/wiki/Avalanche_effect)
是否沒有XKCD漫畫中有一個人向他的同事吹噓他的新密碼在他的超級安全密碼管理器中有多複雜,冗長和“困難”。然後他站起來給自己喝杯咖啡。當另一個坐下並開始寫下存儲在密碼管理器中的密碼時。
@sbecker我不記得它是xkcd條。如果找到它,我可以找到鏈接嗎?
@Baldrickk我也不記得是xkcd條。經典的https://xkcd.com/538/聽起來有點相似。
您確實應該查看NIST 800-63-3,並查看他們對密碼(“存儲的機密”)提出了哪些建議。
希望您的不錯的哈希算法是pbkdf2,bcrypt,scrypt,argon等中的一種。因為當我聽到人們談論含鹽哈希時,它主要意味著某種sha512。那些使用適當的密碼哈希算法的人根本不會提到salt,因為它是內置的。我只是說說“ salted hash”有難聞的氣味,表明缺乏知識。
@Dissimilis:我的編輯是針對那些尚未與這些算法合作的人的,他們可能對他們的工作並不了解。我不想對它們進行糾正而聽起來很粗魯,所以我用樸素的英語在“編輯”下發布了內容。我感謝您的關心,感謝,並確實相信我,“ nice”,我的意思是一個很好的算法。我是在security.stackexchange上長大的,聽聽像你們這樣的偉人,請相信我!
十 答案:
schroeder
2018-05-05 01:06:39 UTC
view on stackexchange narkive permalink

在線計算器的結果基於一組特定的假設,這些假設可能不適用於任何情況。沒有理由相信計算器可以提供有關攻擊者可能如何選擇破解密碼的任何見解。

例如,如果我知道您使用的是什麼模式,以及該模式是什麼,那麼我會調整我的蠻力以適應模式。在線計算器無法解決這一問題。還有其他類似因素需要考慮。 “熵”就是要確保盡可能多的隨機性。設置模式的隨機性大大降低,而與所使用的字符無關。

因此,是的,如果滿足您的目標,請禁止使用這些明顯的模式。

不過,我確實對您禁止這些密碼的方法感到擔憂。您可能在打錯仗。

即使您不知道所使用的特定模式,諸如Hashcat之類的工具的規則集也將應用最常見(甚至不常見)的模式及其所有變體。
感謝您的答复,對此深表謝意。這個網站正在談論但並未透露名稱,每個道德/不道德的黑客,幾乎所有使用堆棧交換的用戶以及所有大/小公司(因為他們使用它的服務)...這就是為什麼我來這裡尋求建議的原因。除了“大大減少的隨機性”外,數據庫中又一次出現了一組類似的密碼,引起了我們的注意。
“一組相似的密碼,一次又一次地在我們的數據庫中”:您是否以純文本形式保留密碼?到目前為止,這將是更大的安全問題。您應該對它們進行散列處理(使用獨特的鹽),這將使這種事情無法輕易注意到。
-1
“在我們的數據庫中,這是一組類似的密碼,一次又一次地引起了我們的注意。”您在OP和註釋中都做出過這樣的聲明,這使我們很多人都假設您要么將它們存儲為純文本格式(已拒絕)或您正在使用沒有[雪崩效應](https://en.wikipedia.org/wiki/Avalanche_effect)的哈希算法(否則,您怎麼會知道它們是相似的?)。後者當然要好一些,但兩者都不好。
這些在線計算器中的大多數都採用了過時的技術和搜索算法。
+1為最後一段。這正是我閱讀問題時的想法。
我不太確定這個答案。啟發式地很容易為這些密碼分配一個較低的熵值。但是啟發式分析的前提是您已經可以猜測熵到ASCII編碼方案,為此,還有另一組熵。我認為BTC借助BIP39獲得了正確的平衡...
Luis Casillas
2018-05-05 02:28:43 UTC
view on stackexchange narkive permalink

出於好奇,我在一個非常知名的網站上(在其登錄頁面上)進行了檢查,並指出要打破它需要幾個世紀的時間。

此類網站不能被當作福音。許多都是一文不值的,即使是好的,結果也必須仔細解釋。首先,作為一般規則,強度檢查器可以最終告訴您密碼是弱密碼,但不能真正向您證明密碼是強密碼–無法找到錯誤的密碼很可能會受到某種攻擊,儀表不建模。對於某些極端的例子,這篇 Ars Technica 文章描述了對一些其他令人印象深刻的長密碼短語的成功破解攻擊

幾乎立即,曾經很頑固的密碼顯示了自己。他們包括:“我會再見到你的臉嗎?” (36個字符),“開頭是單詞”(29個字符),“從創世到啟示”(26),“我什麼也記不清”(24),“ thereisnofatebutwhatwemake”(26),“ givemelibertyorgivemedeath”(26 )和“月亮的西向東”(25)。

另一件事是,僅僅因為一個儀表告訴您它判斷密碼很強,並不意味著所有此類儀表都可以。例如, zxcvbn檢查器(最好的檢查器之一)認為,如果密碼散列很弱,可以通過脫機攻擊在3小時內破解:

 密碼:23 ## 24 $$ 25 %% 26guesses_log10:14score:4 / 4function runtime(ms):3guess times:100 / hour:centuris(throttleed online Attack)10 / second:Centurys(unthrotched online Attack)10k / second:centuries(離線攻擊,慢速哈希,許多內核)10B /秒:3小時(離線攻擊,快速哈希,許多內核)匹配順序:'23 ## 24 $$ 25 %% 26'模式:bruteforceguesses_log10:14  

估計 1!2 @ 3#4 $ 5%6 ^ 2 @ 3#4 $ 5%6 ^ 7& a 2分鐘! b @ c#d $ e%f ^ 攻擊速度為10B /秒(3年,每秒10k),因此它認為更糟糕的情況。 (儘管它的確獲得了所有4/4的評分。儀表建議您實際上接受這些密碼中的任何一個,因為它估計如果您的應用程序實施了緩慢的密碼哈希操作,它們很可能抵禦攻擊 。但是它的分析實際上證明了它們對您應該緩解的特定攻擊是無能為力的。)

請注意,zxcvbn僅根據大多數用戶如何選擇密碼的常識來對攻擊進行建模-它沒有有關組織的密碼策略或做法的任何特定知識都可能對學習它們的人進行專門的攻擊。永遠記住,該工具可以告訴您密碼很弱,但不是很強-zxcvbn估計要破解幾個世紀才能破解我會再次看到您的臉嗎?,該密碼來自我們知道的Ars 文章實際上已經在現實生活中被破解了。

現在,我對列表感到困惑,如果我將這些特殊類型的密碼標記為易受攻擊並禁止用戶訪問,對於他們來說,即使他們花費很長時間才能破解?問題在於,您不可能成功地編譯出同樣容易受到攻擊的有限密碼列表,也無法成功地構造出攻擊者可能成功利用的模式。例如,要捕獲zxcvbn認為與後三個一樣脆弱的所有密碼,您需要一個包含1.2萬億個條目的列表(10B密碼/秒×2分鐘)。不切實際。即使您嘗試將事情壓縮成一小撮要拒絕的模式,我也不會指望成功地超越攻擊者。

您絕對應該做的一件事是使用具有bcrypt或Argon2密碼哈希功能的強密碼哈希。這就是上述zxcvbn稱為“慢散列”的結果,它可能使密碼輸入更難破解。 (但再次提醒您,強度檢查器可以告訴您某些密碼絕對不安全,但並不安全。)

您還應考慮以下事項:

  • 使用一小千個已知非常普遍的密碼,並禁止使用。這樣的列表可以在網上輕鬆找到。
  • 使用 Troy Hunt的500M +突破密碼列表,該列表也具有在線API。 (請確保您閱讀了關於k-匿名性的材料,所以您實際上沒有將密碼發送給API!)
  • 使用智能強度計庫(例如zxcvbn)
  • 採用第二種身份驗證因素,因此密碼不是您唯一的防線。
感謝您的努力。這種緩慢的哈希值花了幾個世紀的時間才能破解密碼,這就是我們對易受攻擊/不可受攻擊的密碼持不同意見的原因。出於安全原因,我沒有在我們的網站上發布用戶經常使用的不同密碼類型。我們正在經歷的是在數據庫中存儲了類似的哈希值,當我們進行交叉檢查時發現,設置模式正在用戶中吸引更多用戶來創建密碼。上帝禁止,如果我們遭到破壞,那麼緩慢的速度將不會保存這些特殊的密碼,因為它們是可猜測的模式。看一下“ Troy”鏈接,brb。
@Batman,我認為您正在慢慢準備只有一個“安全”且已批准的密碼。您提到的模式不是用戶自願創建的-通過禁止某些密碼**您強迫他們發明這些模式**。您施加的限制越多,您就越迫使每個人進入一種模式。一旦破裂,將是災難性的。更少的規則,更多的教育。糾正馬電池裝訂。
@Batman如果您的數據庫中具有類似的密碼哈希,那麼更深層次的問題是錯誤的。如果您使用的是適當的算法(例如PBKDF2,bcrypt,scrypt或Argon2i),那麼即使每個用戶都使用相同的密碼,他們也會具有不同的哈希值。如果相同的密碼導致相同的哈希,那麼攻擊者將獲得巨大的優勢,因為他們可以同時破解每個人的密碼。如果該算法被廣泛使用,那麼甚至可能會有現成的彩虹表可用。
@Agent_L:我們並沒有強迫任何人使用一組固定的密碼模式,只是添加了一個符號,總長度大於或等於8的數字才是規則。但。我猜想,我們可能必須對密碼創建設置某些限制,因為在金融領域,用戶的數據保護是當務之急。
-1
-1
“要捕獲zxcvbn認為與後三個一樣脆弱的所有密碼,您需要一個包含1.2萬億條目的列表”。可以通過在位級別上計算自相關來檢測此密碼的弱點-對於4個字符的移位,自相關將非常高。
@Batman如果您的用戶開始共享模式如何欺騙您的限制,那麼這些限制對他們來說太難了,這將帶來巨大的安全風險。一些用戶(例如書呆子)可以記住數字和符號,而其他用戶(幾乎可以休息)則不能記住。您需要教育用戶。
@Agent_L-“您需要教育用戶”,指出。我們確實有非常老的客戶(受尊敬的客戶),他們在設置新密碼時可能會遇到問題,當您說教他們時,您是對的。
Steve Sether
2018-05-05 06:37:18 UTC
view on stackexchange narkive permalink

密碼的可理解性意味著了解人們可能會選擇的密碼種類。我們都知道“密碼”是可猜測的,因為它是一個英文單詞。但是要知道您需要要么英語,要么對英語或其他相關語言如何拼寫單詞有所了解。來自Betelgeuse附近某個從未接觸過英語或另一種人類語言的外星人不會知道“ Password”很容易猜到。換句話說,模式在某種程度上是主觀的,(超過一定水平)使它們很難預先進行預測。

類似地,對於列表中的某些密碼,立即發現的密碼並不清楚模式是。 1!2 @ 3#4 $ 5%6 ^乍看之下似乎有些“隨機”,但是您會很快注意到,在QWERTY鍵盤上,它簡直是1-6,並用Shift鍵交替顯示其他所有字符。

此外,如果有人向您顯示密碼CPE1704TKS,您可能也會認為它是一個很好的密碼。它具有10個字母和數字字符,沒有可確定的可重複模式,並且不是任何人類語言中的單詞。不過您會錯的,這不是一個很好的密碼,因為它是在電影《戰爭遊戲》結束時用來發射核導彈的密碼。

因此,使用“可破解性”計算(基於長度和字符選擇)在很大程度上來自虛假網站。此外,它們依賴於獲得密碼哈希的人,這本身是一個重大的安全折衷。它們是雙重偽造的,因為它們暗示您知道哈希需要多長時間。散列速度取決於您選擇的算法,變化幅度很大。因此,將“易碎性”分數與一粒鹽一起考慮。如今,大多數對密碼的攻擊都使用普通密碼,或者重用的密碼而不是被盜用的密碼哈希。

確實,這歸結為只是維護了其他人多年來發現的具有某些特殊含義的“錯誤密碼”列表。我的猜測是安全人員從那裡來。

關於“僅維護其他人多年來發現的'錯誤密碼'列表”:或僅使用[其他人的列表,可能比您的列表大得多](https://haveibeenpwned.com/Passwords)。
@Ben我不確定您在說什麼。我並不是說您應該獨立於其他任何列表來維護自己的列表,而是要在維護列表時考慮其他人的列表。實際上,確定什麼對您有意義。例如,禁止5億個密碼可能並不是每個人的正確方法。
“如今,大多數密碼攻擊都使用通用密碼或重複使用的密碼”-同意。
leftaroundabout
2018-05-05 16:03:07 UTC
view on stackexchange narkive permalink

不可能證明給定的密碼很難破解。

(正確)聲明這些“高度脆弱”的意思是存在一種用於生成它們的更容易猜測的算法,即“以這種簡單的方式擊中QWERTY鍵盤的數字行”。對於一整天都在用這種鍵盤按壓手指的人來說,這恰好是一種算法,但是這種鍵盤上的模式實際上“對計算機不敏感”,因為實際上大多數計算機程序都不會我完全不在乎鍵的物理佈局。

我同樣可以給出一個示例,例如 YWJjZGVmZ2hpamts ,您可能會認為這是一個相當安全的密碼,但是您實際上會錯,因為它恰好是字符串 abcdefghijkl 的Base64編碼,對於AI字符串主要是位模式。

將給定的信息位表示為多麼簡單的概念稱為 Kolmogorov複雜度。儘管定義很簡單,但這實際上是一個非常棘手的概念:它高度依賴於您要表達所有內容的語言,並且是不可計算的。實際上,您最好的辦法是使用具有大型標準庫的富有表現力的編程語言來評估所有可能的短程序,但是,如果這不成功‡ sup>,則絕不能保證不會熵的一種方法,以另一種語言計算密碼,該語言包括一個關鍵的標準函數。如果您不了解QWERTY佈局,您可能還會認為 asdfqwerzxcv 是安全的,儘管您一眼就知道它是完全顯而易見的。

結果:如果您確實找到了給定密碼的任何低熵表示形式,那麼可以,請禁止使用它。但是,絕對不要以任何人(包括任何程序)的斷言為準,如果他們不知道密碼是如何實際生成的,則該密碼是安全的。如果要保證密碼真正不可破解,唯一的方法就是確保它們來自量子力學物理隨機過程。


† sup> 但是,任何與密碼破解有關的程序都應該知道鍵盤佈局,因為眾所周知,人類傾向於採用這種模式。另外, 23 ## 24 $$ 25 %% 26 非常容易,即使無需也不知道鍵盤佈局,因為數字行幾乎以ASCII排列。因此,這些網站在這裡確實做得很糟糕。 sub>

‡ sup> 這甚至不考慮運行時問題。您在這裡所做的工作與強行使用未知密碼一樣困難。 sub>

_“如果給定的密碼不知道密碼是如何實際生成的,則該密碼是安全的” _, 通過說“量子力學物理隨機過程”生成的密碼實際上並不能使密碼更安全。 如果我的硬件隨機數生成器輸出建議的密碼“ Password”(這是極不可能的,但並非不可能)。然後,實際上,它就像我一直選擇“密碼”作為我的密碼選擇它一樣安全(或安全)。
知道生成方法可以告訴您該方法生成安全密碼的傾向,但是卻不能告訴您使用該方法生成的給定密碼的安全性。要了解這一點,您不需要了解您的**用戶**,您需要了解您的**攻擊者**。除了這兩個句子外,您的答案實際上是關於哪個的。
@LyndonWhite“不太可能,但並非不可能發生” –在只有八個字符的情況下,這在一定程度上是有效的。通常,將指數上不太可能發生的事件視為_impossible_確實有意義。從技術上講,您的密碼檢查方法也有可能在錯誤的時刻被宇宙射線穿過處理器並將返回值從false翻轉為true打斷了,但是如果您始終考慮所有這樣的事實,則不是絕對不可能的場景
特別是,這實際上是我要說的主要部分,您可能無法了解攻擊者。您可以知道他們可能會嘗試的某些事情,並且針對這些問題進行過濾當然很有意義,但是您不知道他們不會嘗試什麼。因此,如果沒有關係,他們嘗試什麼策略是最安全的。
確實,這是公平的,所以我的主要觀點是,您(系統的維護者/系統)知道的有關*用戶*生成密碼方法的信息實際上與該用戶密碼的安全性無關。對於**用戶**,您關於使用隨機過程生成密碼的觀點(總的來說,是許多密碼)。從“維護者/系統”中獲取它們的方式無關緊要。您的最後一句話基本上不成立,與** maintaner / system **的生成方式無關。就是這樣。
@LyndonWhite不,我不同意:_它是什麼_無關緊要。單個密碼的安全性最終是毫無意義的概念(同樣,除了一小部分pwds明顯不安全)。這只是可以通過熵客觀地評估的生成方法。是的,無論維護人員還是用戶,使用哪種_particular_方法都無關緊要,但是生成器的熵才是重要的。
reed
2018-05-05 02:04:18 UTC
view on stackexchange narkive permalink

如果需要,可以將類似“ 12345678”的密碼視為隨機密碼。如果使用隨機密碼生成器,則生成“ 12345678”的可能性與“ 4h2Ud8yG”的可能性相同(僅考慮字母數字密碼)。如果您在“ 00000000”至“ ZZZZZZZZ”範圍內隨機強行破解,則“ 12345678”很難像“ 4h2Ud8yG”一樣難以破解。但是事實是密碼不應該只是隨機的,它們也應該看起來是隨機的。為什麼?由於攻擊者通常會使用基於字典或模式的暴力破解,因此非基於單詞或模式的密碼更加安全。同樣,如果使用文字和圖案使密碼更容易記住,那麼同一個人使用的所有其他密碼很可能會以相同的方式更容易記住。因此,如果攻擊者竊取了您的密碼之一,並且看起來像“ John75”,則他們很可能會通過強行使用“名稱+數字”,“單詞+數字”或某些變體的方式破壞您的大部分密碼。但是,如果攻擊者竊取了您的密碼之一,並且看起來像是“ 4h2Ud8yG”,那麼他們將無法從中提取任何信息。

所以當您說出這些密碼時,您是對的並不是很安全。它們甚至沒有您認為的所有熵!這是因為密碼熵是基於密碼的外觀或密碼的創建方式。像“ 1!2 @ 3#4 $ 5%6 ^”這樣的密碼,如果您將其想成“數字後跟符號,六次”,則將有(10x10)^ 6 = 10 ^ 12的可能性。這比由小寫字母和數字組成的簡單8字符密碼的可能性要小:36 ^ 8 = 2.8 x 10 ^ 12可能性。但是,如果您想到該示例密碼,例如“同一鍵上的數字和符號,從1升序開始,六次”,那麼總的可能性就是……只有一種!

確切地說,它們應該具有足夠的Kolmogorov複雜度。
keithRozario
2018-05-07 14:03:32 UTC
view on stackexchange narkive permalink

首先,這些密碼強度指示符是指南,而不是絕對真實。

其次,密碼的安全性或破解所需的時間取決於幾個因素。為了更好地理解這一點,重要的是首先要了解密碼是如何“破解”的。

密碼共有3種常見攻擊:

  1. 攻擊者嘗試登錄到攻擊者通過猜測密碼來發現服務
  2. 攻擊者在另一個漏洞中發現了相同的用戶名/密碼組合,現在正將其用於未破解的服務(憑證填充)
  3. 攻擊者獲得了數據庫服務轉儲,並具有密碼哈希。現在,他們正在強行使用哈希來確定純文本密碼。
  4. ol>

    為防止攻擊者直接猜測密碼,我們實施了某種“熵規則” AND 我們限制登錄嘗試的次數。這樣,攻擊者就無法直接對您的服務進行暴力破解。

    要防止憑據填充更加困難。無論您強制使用多強的密碼,如果用戶使用該密碼,都會無濟於事在一個單獨的被破壞系統上具有相同的密碼-並且該系統以明文形式存儲了該密碼!

    一些公司(尤其是Amazon,LinkedIn和OpenTable)甚至正在訪問數據洩露並警告其客戶-即使這些違規行為不在公司所說的。這有助於防止憑證填充(有點!),但可能有點過頭。

    最後,典型的暴力破解是強制使用密碼哈希。這是攻擊者以某種方式掌握用戶密碼哈希的地方,現在正試圖從哈希中猜測明文。在這裡,我們通常會聽到要打破音符需要幾個世紀的時間。

    通常,攻擊者將使用ocl-hashcat之類的工具與常用密碼(例如RockYou或Top1000密碼等)的單詞列表結合使用來猜測純文本。攻擊者還可能強行使用字母,數字和特殊字符的每種組合,但這並不常見,因為它的效率不如單詞表。

    要減慢攻擊速度,通常我們需要依靠:

  • 使用強大的哈希函數(使用Bcrypt代替MD5)
  • 對單個密碼(強制攻擊者一次暴力破解)
  • 防止用戶使用弱密碼
  • 防止用戶在以前的數據洩露中使用密碼(因為單詞列表由以前破壞的密碼組成)

對於最後2項, NIST建議以下內容:

在處理建立和更改存儲秘密的請求時,驗證者應比較針對包含已知被普遍使用,預期或折中的值的列表的預期機密。例如,該列表可以包括但不限於:

  • 從先前的違規語料庫獲得的密碼。
  • 詞典詞。
  • 重複或連續字符(例如'aaaaaa','1234abcd')。
  • 上下文相關的單詞,例如服務名稱,用戶名及其派生詞。

很明顯,一旦發現服務漏洞,服務應該強制重置密碼。

簡而言之,不要迷惑幾個世紀來打破廢話。採取一系列合理的保護密碼的做法,您應該會很好,不要完全依靠這些密碼強度指標來確定您的安全狀況。此 NIST鏈接是一個很好的起點。

Tom
2018-05-07 01:50:58 UTC
view on stackexchange narkive permalink

大多數在線密碼建議是友好的,沒有任何堅實的基礎。這尤其適用於所謂的密碼複雜性,它基於80年代的神話,而且幸運的是-在NIST的原始作者去年承認它之後-即將退出。

您可以 不能在不了解您實際威脅的情況下估算密碼強度。所有瑣碎的在線計算器都是胡說八道,因為它們只是在做一些數學運算而沒有考慮您要反對保護的內容。

您的威脅可能是強行攻擊強>。在這種情況下,第一件事就是不允許暴力攻擊。如果某人輸入了錯誤的密碼一百次,但您沒有將其鎖定,則說明您做錯了與密碼強度無關的事情。第二件事是 length> complex

如果您的威脅是對密碼哈希的字典攻擊,那麼要做的第一件事就是正確保護哈希。第二個方法是使用適當的哈希函數(bcrypt,scrypt等,而不是MD5或SHA1)適當地加鹽和哈希。第三是不允許簡單的字典單詞和排列。使用與解密者相同的邏輯,其中一些是公開可用的。強制執行,並確保您的用戶實際上可以記住他們的密碼,然後快速鍵入它們。同樣,長度>複雜度。最小長度為12個字符,但允許使用複合詞。

以此類推...

總之:考慮到您的威脅,不要相信瑣碎的數學估算。

一個有趣的事實:當我在最近關於密碼安全性的演講中準備時,事實證明很多在線密碼工具都認為ABCabc123!“§是一個非常安全的密碼...
令人討厭,因為您將整個問題提煉成最後一句話。蠻力計算器將“ 123456789”與任何其他9個字符的密碼一樣對待,即使我們人類通常認為它“更容易”破解,因為我們並不是純粹出於蠻力的考慮。如果攻擊者正在使用蠻力(並且僅是蠻力),則答案與使用其他任何方法的答案大不相同。
Peter Green
2018-05-07 18:41:23 UTC
view on stackexchange narkive permalink

出於好奇,我在一個非常知名的網站上(在其登錄頁面上)檢查了此內容,並指出要打破它需要幾個世紀的時間。

如此聲明始終是高度可疑的。

根本的問題是,要計算攻擊者破解密碼所需的時間,您需要一個攻擊者模型。

理想化的攻擊者將按從高到低的順序嘗試輸入密碼。當然,真正的攻擊者不知道任何給定密碼的可能性,因此他們不得不猜測,他們通常會結合使用某種詞典(如果攻擊者有些能力,那麼詞典中不僅會包含常規英語單詞,還會包含很多詞典)。一堆生成規則。

問題在於,密碼強度計使用的攻擊者模型通常在字典的大小和規則的複雜性方面遠遠落後於實際的攻擊者。


密碼限制的根本問題是,無論您對用戶施加什麼限制,他們通常都會竭盡所能來使密碼通過。

現在,這可以添加一些熵,通常,不只一種最簡單的最小方式來更改密碼,這樣它就可以通過規則,但是所添加的熵比天真的分析建議的要小得多。例如,如果您強迫用戶向其密碼添加數字,那麼他們中不成比例的數字可能會選擇1。

MauganRa
2018-05-05 18:39:51 UTC
view on stackexchange narkive permalink

您可能會感到困惑,因為假設可以事先定義密碼漏洞。相反,它很大程度上取決於實際的攻擊者將首先嘗試哪種模式。機會主義的攻擊者可能會首先嘗試使用字典或洩露的密碼列表。但是,即使付出適度的努力,它們也可以變得非常精確。這就是為什麼在密碼準則上實施失敗的原因。大多數準則鼓勵用戶在選擇密碼時遵循某些最低要求。 這可以幫助暴力對待他們。例如,

  • 密碼的最小長度為X個字符,攻擊者可以避免嘗試使用所有小於X的密碼,而將注意力集中在長度為X,X + 1或X的密碼上假設許多用戶僅滿足最小長度要求,則為+2。

  • 強制執行“小寫,大寫,數字和特殊字符”之類的模式,攻擊者可以假定存在使用正是這種模式導出密碼的用戶。

  • 可以向他們反饋密碼是否為洩露的密碼,但是在那裡是他們最終修改它直到通過的風險。同樣,這也向攻擊者暗示瞭如何指揮其蠻力攻擊。

  • 最大長度很明顯。在最佳情況下,長度會降低使用密碼管理器的好處。在最壞的情況下,它們可以提示登錄系統的潛在技術限制。此外,它們為攻擊者必須付出的最壞情況下的努力設置了上限。

您對密碼的長度分析非常正確,我們當然不能做很多事情,但是,可以肯定的是,我們可以限制密碼不遵循某種模式。
jmoreno
2018-05-08 06:51:29 UTC
view on stackexchange narkive permalink

要確定密碼破解的難度,您必須知道密碼的熵,這些站點顯然無法知道。他們會做出最好的猜測,然後將其返回。

為了正確地計算密碼的熵,您必須假設攻擊者與創建者一樣了解如何創建密碼。如果創建者總是包含兩個10個字母的單詞之一,那麼攻擊者必須知道這些單詞之一將存在以及它們的含義。

由此您可以看到您的模式非常低熵(不超過7位)。但是由於網站不知道,所以他們對它的評價更高。如果您想要一個好的密碼,則必須具有隨機性。如何使用戶接受並在密碼中包含隨機性是個問題。最好嘗試弄清楚如何讓別人去做密碼或等效密碼。



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