不止一次，我被要求爲我正在開發的軟件選擇密碼選擇規則。典型的建議包括了諸如：密碼複雜性策略 - 他們的任何證據？
依此類推。
雖然通過限制可用密碼，可以減小所有可用密碼空間的大小，但有些東西總是會對我的任何限制進行密碼限制。這難道不會讓更容易猜測嗎？同樣，通過讓用戶創建複雜且經常變化的密碼，寫入它們的誘惑力增加，同時也降低了安全性。
是否有任何量化證據表明密碼限制規則會使系統更安全？
如果有，那麼使用哪種「最安全」的密碼限制策略？
編輯奧拉維爾Waage欣然指出了Coding Horror article on dictionary attacks其中有很多有用的分析，但它給我的印象是字典攻擊可以大量減少（傑夫建議）通過簡單地添加延遲認證嘗試失敗後。
考慮到這一點，有什麼證據表明強制複雜密碼更安全？
東西一直竊聽我關於 穿上密碼 任何限制，雖然 - 通過限制可用的 密碼，可以減少所有允許密碼的 空間的大小。 這難道不會讓密碼更容易猜到 嗎？
理論上，是的。在實踐中，您拒絕的「弱」密碼代表所有可能密碼的一小部分，在沒有限制的情況下通常會選擇不成比例的密碼，並且哪些攻擊者知道先攻擊。
同樣，通過使用戶創建 複雜的，經常變化的 密碼，誘惑寫 下來的增加，也減少了 安全。
正確。強迫用戶每月更改密碼是一個非常非常糟糕的主意，除非在每個人都真正理解安全需求的極端高安全性環境中。
在這讀了一個很好的傑夫對Dictionary Attacks.
這些類型的規則文章絕對有幫助，因爲它停止愚蠢的用戶使用的密碼，如「輸入mypassword」，不幸的是常有發生。
所以實際上，你迫使用戶輸入一大組潛在的密碼。不要緊，你只用小寫字母來排除所有密碼的集合，因爲剩下的集合仍然大幾個數量級。
但我的寵大的眼中釘是我在各大網站上遇到密碼限制，像
爲什麼會有人這樣做？爲什麼。？？？？
雖然這並不能直接回答你的問題，但我個人發現我遇到過的最激烈的規則之一，因爲你不能重複使用以前使用過的任何密碼。在同一地點工作多年後，每2/3個月不得不更改密碼，使用我在一年前選擇的密碼的能力似乎並不特別不安全或不安全。如果我以前使用過「安全」密碼（字母數字和大小寫更改），那麼在一年或2年之後（取決於您經常更改密碼的頻率），確定重新使用它們似乎對我來說是可以接受的。這也意味着我不太可能使用「更簡單」的密碼，如果我想不出任何容易記住和難以猜測的事情，可能會發生這種情況！
「以前的密碼」限制更多的是入侵檢測，而不是密碼安全。如果攻擊者設法重置您的密碼，那麼他們可以將其重新設置爲之前的值，然後您不會知道他們曾經通過重置進入。然後，如果他們沒有將其設置恢復到之前的值，但您又設法返回到您的帳戶，那麼如果他們知道由於入侵事先設置的內容，您仍可以保留訪問權限。 – 2015-02-08 15:04:47
人們也可能會指出最近在Twitter上的失敗，其中一個管理員的密碼竟然是「快樂」，而後者卻被字典攻擊所困擾。
對於這樣的問題，我問自己what Bruce Schneier would do - 鏈接的文章是關於如何選擇難以用典型攻擊進行猜測的密碼。
另請注意，如果您在嘗試失敗後添加延遲，則可能還需要在成功嘗試後添加延遲，否則延遲只是一個信號，表明攻擊失敗後應該啓動其他嘗試。
成功嘗試後的延遲對用戶來說是一個很大的煩惱，並且不會隱藏任何更多的信息，因爲還有其他方法來測試失敗。 – 2011-09-05 19:40:40
我忘記了哪個網站有關於密碼的建議：「選擇一個非常容易記住的密碼，但是很難讓其他人猜測。」但隨後他們開始要求至少有一個大寫字母和一個數字。
密碼的問題在於，它們如此無處不在，以至於沒有攝影記憶的任何人在沒有寫下它們的情況下實際記住它們，因此如果有人可以訪問此列表，就會留下嚴重的安全漏洞寫下密碼。
我能夠自己管理這個的唯一方法就是分割我的大部分密碼 - 而且我只查看了我的列表，到目前爲止我已經達到了130個！ - 分成兩部分，一部分在所有情況下都是一樣的，另一部分是獨特而簡單的。 （對於需要像銀行賬戶那樣的高安全性的網站，我違反了此規則。）
通過要求「複雜性」定義爲多種類型的字符都存在，是它迫使人們針對不同站點採用不同的約定集，這使得難以記住有問題的密碼。
我將承認限制允許的密碼字符集的網站的唯一原因是它需要在鍵盤上鍵入。如果您必須假設該帳戶需要從多個國家/地區訪問，則鍵盤可能不會始終支持用戶家用鍵盤上的相同字符。
其中一天，我將不得不在這個問題上發表博文。 :(
我的老極限定理：
作爲密碼的安全性足夠接近，這將是在連接到電腦或顯示器便條的概率接近1
首先讓我。說最小長度，區分大小寫以及所需特殊字符等細節應該取決於誰有權訪問以及密碼允許他們做什麼，如果是啓動核導彈的代碼，那麼它應該比密碼更嚴格以便登錄發揮你付費的在線版憤怒的小鳥
但我有一個SPE CIFIC牛肉與大小寫敏感。
對於初學者，用戶討厭它。人腦認爲「A = a」。當然，開發人員的腦子通常並不典型。 ;-)但是開發人員也會因區分大小寫而感到不便。
其次，CapsLock鍵太容易被誤操作。它正好在Tab和Shift鍵之間，但它應該高於Esc鍵。它的位置早在打字機的日子就建立起來了，它沒有備用字體。在那些日子裏，有它在那裏是有用的。
所有密碼都有風險...您將風險與易用性平衡，是的，可用性很重要。
我的理論： 是的，區分大小寫對給定的密碼長度更安全。但除非有人讓我這樣做，否則我會選擇更長的密碼長度。即使我們假定只允許字母和數字，每個添加的字符都會將可能的密碼的數量乘以36.
有些人比我數學懶惰可以告訴您組合之間的組合數量的差異，例如最少8 - 特徵區分大小寫密碼，以及12個字符的不區分大小寫的密碼。我認爲大多數用戶會喜歡後者。另外，並非所有應用都向其他用戶提供用戶名，所以黑客有可能需要找到兩個字段。
我也喜歡，允許在密碼空間，只要廣大的密碼是不空格。
在我正在開發的項目中，我的管理屏幕允許管理員更改適用於所有未來密碼的密碼要求。他還可以強制所有用戶在下次登錄後隨時更新密碼（以滿足新的要求）。我這樣做是因爲我覺得我的東西不需要區分大小寫，但管理員（可能爲我支付軟件費用）可能不同意，所以我讓這個人決定。
我的銀行卡的PIN只有4個數字。由於它只是數字，因此不區分大小寫。而且，這是我的錢！如果你不考慮其他什麼，這聽起來很不安全，是不是因爲黑客必須偷我的卡才能拿到我的錢。 （並且拍下他的照片。）
另一個牛肉：開發人員來到StackOverflow並反芻他們在某篇文章中讀到的硬性規則。 「從不硬編碼任何東西。」 （好像這是可能的。）「所有查詢都必須參數化」（如果用戶不參與查詢）。等等。
請原諒咆哮。 ;-)我保證我尊重分歧。
對於這個問題，我傾向於根據輸入文本的特徵爲密碼提供'分數'，並拒絕不符合分數的密碼。
例如：
Contains Lower Case Letter +1
Contains different Lower Case Letter +1
Contains Upper Case Letter +1
Contains different Upper Case Letter +1
Contains Non-Alphanumeric character: +1
Contains different Non-Alphanumeric character: +1
Contains Number: +1
Contains Non Consecutive or repeated Second Number: +1
Length less than 8: -10
Length Greater than 12: +1
Contains Dictionary word: -4
那麼只有具有大於4的得分，（當他們通過javascript創建他們的密碼爲用戶提供反饋）
I *允許密碼討厭*最大密碼長度。 GRRRR！ – Dana 2009-01-19 13:13:44