題:
為什麼經常使用靜態密碼要求?
HopefullyHelpful
2016-11-17 14:42:01 UTC
view on stackexchange narkive permalink

測量密碼熵並拒絕低熵密碼會更聰明嗎?

這將允許使用整個字符集的短密碼以及僅使用部分字符集的長密碼通過

以上方案是否可能,或者實現細節是否阻止了類似的事情?

任何站點或程序是否已包含此類密碼要求?

如果只告訴我“您的密碼不夠強”而沒有告訴我如何使其更強(使用“加27位熵”不是很有幫助),那麼使用這樣的密碼輸入表單可能會有些煩人。
基於整個可打印/可輸入字符空間的隨機8字符密碼包含多少熵(偶然且完全隨機地僅包含ASCII字符)?
@ Matti“熵”對用戶不是有用的參考,但是該值可以在通常的一周內顯示為強滑塊,同時向用戶提供有關如何增強其密碼的常規建議。我認為OP提出的要點就是為什麼諸如“必須包含一個特殊字符”之類的要求會迫使用戶在使用較長的無特殊字符的密碼時與選擇較短的特殊字符一樣強的原因,從而迫使用戶做出某些密碼選擇。
問題在於,沒有可靠的方法來計算字符串的熵……總會有一些錯誤的密碼使它變得笨拙。通過使用靜態限制,例如“至少12個字符,必須包含字母,數字和密碼”,您至少可以保證一些最低要求...
斯坦福大學在幾年前為其用戶實施了自適應密碼策略系統:https://uit.stanford.edu/service/accounts/passwords/quickguide
密碼沒有熵。*密碼生成方法*具有熵。
@n00b每個人都知道“正確的大腦電池裝訂”是最強的密碼,並且實際上是不可破解的!每個人都應該使用這個!-結束笑話模式-真正的問題是人們幾乎每次都會選擇弱密碼。您需要的是一個自動分配密碼的系統,其中的熵是已知的(並且很高)。用戶不應“僅僅因為他們不喜歡它”而不能更改它,因為這會減少熵。
那麼,@CJDennis會讓用戶執行*其他*不安全的做法,例如將其PW寫下在監視器旁邊的粘滯便箋上,而沒有機會記住`?_2Amd =,_} eZ <#j`。
-1
@CJDennis顯然是基於單詞的。問題是,大多數公司仍然堅持“越怪異的字符越好”的想法,迫使我使用一個相當強的密碼(根據ZXCVBN),並在`@`中輸入`a`,在$$中輸入`s`。等等,僅僅是為了滿足自己的力量標準。不幸的是,我不得不減少字符數,因為鍵入隨機大寫字母和符號要花更長的時間(如果您必須連續鍵入1000次,它是一個很好的腕管生產商),而如果它只是4-6個帶有空格或下劃線的隨機單詞,不可能破解。
可以將@Mark密碼熵定義為足以使用通用密碼生成方法生成密碼的最小熵。無論如何,這就是破解方式。
十一 答案:
ChristianF
2016-11-17 17:52:29 UTC
view on stackexchange narkive permalink

著名的XKCD地帶之後,有一些項目開始處理這種熵檢查。其中之一是Dropbox員工製作的 ZXCVBN密碼檢查器

它可能是同類中最完善的密碼檢查器。它檢查模式,單詞等,從而相應地增加(或減去)熵值。 在他們的博客上詳細解釋了

我相信這是基於Web的版本:https://dl.dropbox.com/u/209/zxcvbn/test/index.html
嗯...我認為我不會在隨機網絡工具中輸入密碼...
@IonoclastBrigham,但是這個特定工具似乎並沒有在背後打來電話,不是嗎?
人們也應該始終警惕在基於Web的網絡中輸入實際密碼。但是,在這種情況下,這只是演示ZXCVBN如何工作的演示,因此應與密碼示例一起使用。它不能替代您自己在站點上實際實施它。
@s.m您忘記添加“在撰寫本文時”
如果您確實很偏執,可以在使用表格時關閉網絡適配器。
看起來它全都是客戶端JavaScript。但是,如何輕鬆地驗證這一點呢?
如果沒有進行任何操作,則不會證明沒有進行任何操作。將此功能與暫時禁用請求或類似功能的Web代理相結合,至少可以確保發出請求時失敗。
AviD
2016-11-17 14:55:34 UTC
view on stackexchange narkive permalink

這是一個好主意,實際上,這是衡量密碼強度的唯一正確方法。

但是您如何衡量密碼的熵呢?
熵是生成過程的一個方面,而不是輸出的一個方面。

例如,對於 Tr0ub4dor&3 這樣的度量的輸出是什麼?通過基於給定密碼的任何可能的熵的合理度量,這將相當不錯-超過70位的熵。或者,也許考慮到假定的密碼生成過程,我可能很聰明地意識到它實際上只限於28位,因為每個字符都不是隨機選擇的,而是首先選擇一個完整的單詞。但實際上,我應該完全廢棄整個想法,因為我顯然只是直接從漫畫中復制了它。

如果密碼是正確的馬蹄鐵釘書釘(在特定人群中最流行的密碼之一),則會出現相同的問題。

是的,密碼要求應該基於密碼的熵,但是事後您不能將此要求應用於給定的密碼。

(順便說一句,正如我在關於該主題的另一個答案中提到的那樣(從另一個方向),實現一個密碼/密碼短語自動執行的系統可能是一個好主意-為給定的熵級別生成並提供給用戶,而不是要求用戶提供滿足我們要求的密碼。當然,這是一個好的密碼管理器將在客戶端上執行的操作……)

我認為唯一可能的方法是為所有流行的OS配備系統標準庫,其中包含最先進的密碼字典,然後查找密碼位置。否則,您將不得不在js中發送密碼字典/破解器,這將花費大量資源。或者,您可以將明文或rsa編碼的密碼發送到服務器。我猜到那時,對於大多數服務器而言,該過程將過於昂貴。
我不明白-只是為了可能?為了計算密碼的熵,您實際上不需要破解它,也不需要任何字典-您只需要檢查生成過程中的隨機性即可。就是這樣,不需要蠻力猜測。
是的,但是密碼熵只是描述近似破解密碼需要多長時間的一種度量。如果要確保用戶未使用“ Tr0ub4dor&3”,那麼您將不得不猜測用戶的創建過程,因此您可以製作一個字典來查找其密碼,以查看其密碼是否強壯。
-1
-1
順便說一句,幾乎可以保證您的服務器在破解密碼時效率不是最高,因此該解決方案的價值更低。
如果人們很難或根本無法記住密碼,他們只需寫下密碼,然後在台式機,筆記本電腦背面以及日曆和手機外殼上貼上一系列便條紙...
當然是@jwenting。因此,我建議為他們提供令人難忘的密碼,或者鼓勵/啟用密碼管理器。
如果我使用gzip和base64“ hello”,則會出現很長的“隨機查找”序列,您可能認為這是高熵,但實際上並非如此。您唯一可以確保密碼的生成是“高熵”的唯一方法是自己生成並發出密碼……但這還有安全交換,易記性等問題。
我認為這個答案太否定了,因為正如ChristianF的答案(間接)所強調的那樣,[zxcvbn密碼表](https://blogs.dropbox.*)中存在*一種合理的方法來提供有用的密碼熵度量。com / tech / 2012/04 / zxcvbn-realistic-password-strength-estimation /):使用統計模型,該模型可以估算密碼如何抵禦我們能建模的聰明攻擊者。這不是萬無一失的,仍然可以改進很多,並且具有令人討厭的“軍備競賽”味道,但是它比密碼組合規則更好。
Cody P
2016-11-17 23:10:49 UTC
view on stackexchange narkive permalink

選擇靜態密碼策略的原因主要有兩個:可用性和證明可接受有效性的研究機構。我的大部分答案來自關於高級密碼強度測試儀Telepathwords的出色研究論文

首先,總結一些用於備份當前密碼策略的研究:

密碼組成規則至少可以追溯到1979年,當時Morris和Thompson報告了用戶在其Unix系統上使用密碼的可預測性。他們提出,密碼長於四個字符,或純字母密碼長於五個字符,將“確實非常安全” [19] [但是] Bonneau在2012年(即33年後)分析了近7,000萬個密碼,以測量六個字符的最低要求與沒有要求 [2]相比的影響。他發現安全幾乎沒有區別……

這包括Komanduri等人的工作。 [13]和Kelleyet等。 [12],他使用類似的研究設計對密碼組成規則進行了比較分析。這些先前的研究發現,密碼長度要求的增加通常會導致可使用性更高的密碼,這些密碼也很難通過其猜測算法[ 13 12]識別為弱密碼。最近,Shay等人研究了要求更長密碼的密碼組成策略,發現最佳性能來自混合最少12個字符和三個字符集的要求 [25]

可用性是為什麼不更頻繁使用諸如密碼熵之類的更複雜標準的重要原因:

在研究密碼的分佈政策,弗洛倫西奧(Florencio)和赫利(Herley)發現,在檢查的75個網站中,可用性要求在安全性方面起著至少相同的作用 [8]。 ...

Ur等。還研究了密碼強度計對 密碼創建。他們發現,當用戶感到沮喪並且對電錶失去信心時,出現了更弱的密碼。 [28]...

儘管[Dropbox's] zxcvbn與僅依靠成分規則的方法相比,其強度估算的可信度有很大的提高, 實際上,如果用戶被告知添加字符會增加密碼強度,而看到添加某些字符會降低分數,則其可感知的信譽可能會受到損害。例如,當鍵入iatemylunch時,添加最終字符後,強度估計值將從第二高的分數(3)降低到最差的分數(1)。即使用戶認為zxcvbn的強度估算值可信,他們也不大可能了解基本的熵估算機制,因此不確定如何提高其分數。 [30]

最後,為了完整起見,我們必須意識到在此示例中定義熵非常困難(但絕非不可能)。關於密碼破解者的猜測算法或字典的複雜程度,我們可以做出許多不同的假設,所有這些假設都會導致對密碼熵的答案不同,例如“ Tr0ub4dor&3”或“正確的電池釘”。。最複雜的密碼熵措施是基於數百萬個密碼的字典和高級密碼模式的研究而來的,這種複雜程度對於許多管理員(和黑客)而言都難以實現。

+1用於實際回答問題“為什麼”而不是“如何以及為什麼進行更改”。
以1到10的比例,用邁克·泰森(Mike Tyson)的聲音閱讀“ Telepathwords”時我會下地獄嗎?
Peter
2016-11-18 04:37:10 UTC
view on stackexchange narkive permalink

熵是根據您創建密碼的方式計算的。 要計算熵,您不需要知道密碼,而是需要知道密碼的創建方式。擁有密碼並不能幫助您計算熵,只能讓您對熵進行非常差的估計。

示例:

Password123

如果我們的密碼“ Password123”是從3個最常用的密碼列表中選擇的,該密碼包含字母,數字,大寫和小寫字母,並且長度超過10個字符,因此Password123的熵值低得離譜。

完美的隨機生成器選擇了相同的密碼“ Password123”,該密碼生成了11位數字的密碼,每個數字都從5000個可能的Unicode代碼點中進行選擇,Password123的熵非常高。


換句話說:您正在做某事,但是“熵”是錯誤的詞-“熵”已經具有不同的含義。您正在尋找的是密碼的“強度”。密碼的強度很難正確衡量,甚至更難以溝通。只要攻擊方法改變,強度也會改變,這一事實也無濟於事。

幾乎所有在線密碼計量器都使用“強度”來表示總錯誤。嘗試使用QWEqwe123!“ $或某些類似的東西(簡單的鍵盤模式),並驚嘆於它們的安全性,儘管每個密碼破解軟件都明確檢查了鍵盤模式,但確實如此。
@Tom確實*“密碼強度很難衡量” *即使公認的答案中鏈接的工具也認為**世界上最常見的25位密碼**“正確的大腦電池裝訂”非常強大。它認為“如何學會停止憂慮和愛炸彈”需要幾個世紀的時間才能破解。
A. Hersean
2016-11-17 15:08:31 UTC
view on stackexchange narkive permalink

您無法測量密碼熵,只能測量其上限。因此,任何密碼強度估計器都是有缺陷的。

使用密碼估計器或令人討厭的規則具有相同的效果,即使用戶嘗試滿足要求,同時使密碼盡可能容易記住。因此,要求越難,他們將越難嘗試建立易於記憶的密碼。例如,使用諸如Pa $$ word1或passwordpasswordpassword之類的密碼。問題在於,容易記住的密碼也是容易猜到的密碼。

當您提供的服務是可選的時,您還可能冒著過高的要求疏遠用戶並失去客戶的風險。

p>

但是,您可以強制使用10個字符的下限,因為所有少於10個字符的密碼都是弱密碼,並且要求不太難滿足。您還可以給他們建議,以建立安全的密碼。但是,我不建議遵循他們的做法。並不是因為別人這麼做,這樣做是一個好主意。

*一個容易記住的密碼也是一個容易猜到的密碼。*這是錯誤的。密碼短語很容易記住,但由於搜索空間很大,因此很難猜測。(他們的問題是,如果您不是快速打字員,他們很容易進入,但這是另外一回事了)
@Tom許多人會不同意您的看法。關於這個主題的研究已經是老新聞了:https://www.schneier.com/blog/archives/2012/03/the_security_of_5.html http://arstechnica.com/business/2012/03/passphrases-only-marginally由於選擇不多,比密碼更安全/
來自您的來源:*“這比密碼要好得多” * –熵的20位而不是熵的10位實際上**好很多**。密碼不是萬能的,這很明顯(“我是神”是一個4字的密碼,但只有7個非空格字符)。
pscs
2016-11-17 18:03:28 UTC
view on stackexchange narkive permalink

如何測量密碼的“熵”?

這是不可能的。

像“ hresda”這樣的密碼可能具有“低熵”,因為它是從小寫字母中選擇的,但是如果它是從一組包含大寫/小寫字母,數字和符號,結果恰好發生,僅包含小寫字母,然後具有較高的熵。諸如“ A63ba!”的密碼如果它是專門為[大寫] [數字] [數字] [小寫] [小寫] [符號]而不是隨機選擇的,則可能比“ hresda”具有更低的熵。

當然,如果隨機框吐出詞典單詞,則生成過程中的熵對您沒有幫助。真正需要估計的是“破解工作”,而對於“ hresda”而言,確實要低得多,而與原始字符集的大小無關。
務實的答案:熵是根據現成的密碼破解工具需要做出的猜測來衡量的。完全可能,並且客觀合理。您可以爭辯說,如果您知道用於生成密碼的規則,則密碼的熵要比出現的_less_少,但是密碼永遠不能比出現的密碼具有_more_熵。
高熵過程生成的任何“低熵”密碼的機率都非常低。就像“在經過嚴格審核的開放源代碼軟件中,很可能會生成一個導致在某些情況下將其鎖定為小寫的錯誤”。比如“我不相信你”。就像“您將一枚硬幣翻轉1000次,它們全都揚起”一樣低。給定從中隨機選擇的高熵空間,任何特定的低熵子空間將變得非常小且不可能。它“可能”發生,可能但並非在宇宙的生命週期內發生。
假設您的系統在密碼生成時具有2000位的熵(強系統!)。6個字符的小寫英文字母的空間大約有28位。生成此密碼的“最大機會”是1972年的二分之一。
我還要補充一點,如果用某種外來語言“ A63ba!”意思是“密碼”,如果外國人決定先嘗試該密碼,則基本上可以立即破解您的密碼。任何密碼的熵的下限始終可以為0。密碼的熵是我們使用自己的信息和知識賦予的密碼。
Noctis Skytower
2016-11-18 03:31:28 UTC
view on stackexchange narkive permalink

是的,有些程序可以測量密碼的熵以確定密碼是否足夠好。一旦這樣的程序是 Wabol Talk。該功能是使用程序主模塊中的 estimate_quality 方法實現的。最終,該方法將在其上方的方法中使用( 錯誤)來驗證用於生成密鑰和初始化向量的密碼字段。這種估計的質量極低,因為它不會根據密碼的使用頻率來判斷密碼,但是它證明了查找密碼中存在多少熵的最簡單方法之一。

雖然`estimate_quality`在拒絕錯誤的密碼方面做得不錯,但實際上並不是對熵的估計。例如,從理論的角度來看,僅採用密碼長度將是更好的熵估計(儘管在拒絕不良密碼方面很差:“ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”)。
在不知道您的“錯誤”示例密碼的長度或設計的情況下,有些人會認為它仍然是一個相當不錯的密碼。
您的理論是愚蠢的,當您看到與通用模式匹配的密碼時,使用該模式創建的密碼比從隨機數生成器中掉出來的可能性要大得多。
這不是我個人的理論。如果密碼中包含十億個字符並且什麼都不知道,則無論密碼的構造方式如何,都可以將其視為固有的安全性(假定攻擊者不知道其構造方法)。
實際上,創建密碼的數據位數比保護該哈希值的哈希返回的位數要多。
@ Noctis Skytower您是否知道為什麼WiFi WPA2使用PBKDF2從160位SHA 1哈希中生成256位密鑰?
為什麼是這樣呢?要么被設計為(有意或無意)那樣,要么犯了一個錯誤。如果決策者願意,過去做出的選擇可能會有所不同。要回答您的問題,請參閱[從PBKDF2-SHA1派生256位密鑰](http://crypto.stackexchange.com/questions/34686)。這樣做並不能使長密碼變得荒唐可笑。如果密碼空間大於哈希空間,則解決“問題”的方法可能比嘗試生成原始密碼更好。
我實際上完全同意您的觀點(在評論中),我的示例密碼具有很高的熵,因為它很長。生成`g)yJa#Hu`和`aaaaaaaaaaa的隨機性絕對相同。我不同意的是,鏈接代碼中的“ estimate_quality”過程估計熵。使用相同的示例,該過程將說`g)yJa#Hu`優於`aaaaaaaaa`,儘管它們的熵應該相等,如果不相等。
那是因為“ estimate_quality”至少做了一個假設:攻擊者將了解有關密碼創建過程中使用了哪些字符集的知識。密碼“ aaaaaaaaa”需要約43位才能以有效格式進行存儲,而密碼“ g)yJa#Hu”則需要約52位以有效格式進行存儲。
TV's Frank
2016-11-18 16:01:47 UTC
view on stackexchange narkive permalink

關於國際環境的說明。如果為面向全世界的網站創建了密碼(這種情況並不罕見),則用戶可能不會說英語作為母語,而是可能選擇瑞典語作為xkcd密碼創建方法的基礎。

“ paraplyost”(繖形奶酪)在知道瑞典語字典的熵檢查器中的排名可能會比不知道該字典的排名低。如果攻擊者知道用戶是瑞典人(不是最常見的情況,但是可能會發生),則他可能能夠比熵檢查器知道的更容易破解用戶密碼,除非熵檢查器中加載了數百(或數千)個

這樣做的一個很好的副作用是,如果您說的語言不是世界上最常見的一種,您可以在匿名用戶上輸入更安全的密碼國際網站。 :)

我認為製作世界上所有單詞的字典不是問題。
Dmitry Grigoryev
2016-11-21 16:33:51 UTC
view on stackexchange narkive permalink

是否有任何站點或程序已經包含了這樣的密碼要求?

幾個網站都這樣做了。例如,轉到 https://www.dropbox.com/login並嘗試使用密碼進行註冊,該密碼是8個字符或更多的普通詞典單詞(例如 dictionary >)。您會看到力量計顯示出最低分。現在嘗試隨機調整字母(例如 ioictnadry )並使用它-您會看到強度計不斷上升。

此方法的明顯缺點是,您需要使用登錄表單將常用密碼的詞典上載到每個客戶端。最近,這種情況還可以,但是5或10年前完全不可接受。

Dick99999
2016-11-18 15:11:26 UTC
view on stackexchange narkive permalink

我的印像是,大多數破解都使用現有的單詞&密碼列表。還有一些變化,例如加數字或重複單詞。

因此,如果密碼出現在列表中,密碼也很弱,但是可能會顯示出很強的(生成過程)熵計算值。 “列表”上的含義是:如果解密者的列表中不包含您的密碼,則儘管有熵計算,但它的強度很高。因此,幾乎不可能事先檢查(未知)列表。不過,嘗試大約6千5百萬個字不會造成傷害,請參閱 Stanford的SUNet ID密碼。 65M數量很多,但此列表包含將近25億個密碼: MySQL密碼

高熵PW生成過程和檢查熵的工具都應輔之以拒絕步驟使用列表和模式。即使是那些高熵的過程也可以生成容易猜到的密碼,例如 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (見下文)和 password1

阿什利·麥迪遜(Ashley Madison)的哈希表如何破解他們發表的長密碼短語。只是一個通用的答案,但在分析了已發布的答案之後,我發現這些長短語中的大多數是通用表達式或哈希標籤,請參見一些破解的AM短語的來源

唯一作為列表來源的例外是密碼,其密碼格式如下:大寫字母,然後是小寫字母,後跟數字。 Internet上可以找到命中%的常見模式。這些確實確實可以很容易地事先檢查。

-編輯調整後的25億;添加了“ aaaaaaa”部分;改寫拒絕

Tom
2016-11-22 17:00:19 UTC
view on stackexchange narkive permalink

一個字:政策

在過去的十年左右的時間裡,信息安全的主要變化是朝著合規性,控制和政策發展。從本質上講,我們今天要做的就是基於C級承諾和公司策略構建ISMS(信息安全管理系統)。

當您編寫密碼策略時,您並不會技術水平。您正在編寫員工需要閱讀,理解並可能簽署的文檔。您正在編寫管理層必須接受和支持的文檔。最後,當您考慮如何實際實施密碼策略時,在幾乎所有組織中,您都無權發明自己的規則。

。您將運行Active Directory之類的東西,並且您的實現必須與之配合使用,或者與IDM系統或舊式堆棧或其他任何東西一起使用。變得半傻,因為這是我們實際上能做到的最好的事情。



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