問題是：更糟糕的是什麼？
使用您發布的策略，可能的密碼少於64⁸（〜2.8 *10¹⁴）。實際上，很多密碼可能是[az] * 6 [0-9] [特殊字符]（例如aabaab1！）和類似的密碼。
所有可能的密碼，相同字符且長度小於8只不過是64⁶+64⁶+64⁵+ ...，約為4.5 *10¹²。那比長度為8的密碼少了很多，因此允許它們使用不會增加太多安全性。 （允許使用更長的密碼顯然會大大提高安全性）
如果沒有任何策略，很多人肯定也會使用錯誤的密碼。但是攻擊者不能確定這一點。另外，有些人會使用更好的密碼。
沒有任何策略，攻擊者永遠無法確定破解密碼的難度。如果您給我一個數據庫的密碼哈希值，我可能會嘗試破解它。但是如果沒有結果，一段時間後我可能會停下來。有了該策略，我可以確定經過64 ^ 8次嘗試後，我將擁有所有密碼。
我會說，錯誤的密碼策略會更糟。
使用轉儲密碼散列，沒有密碼策略，很容易破解任何密碼，但更難破解大多數密碼。 ，更容易破解所有密碼，但更難破解第一個密碼。
如果您擔心的是破解自己的密碼有多難，沒有任何政策，您可以使用安全的密碼如果需要，可隨機輸入20個字符。實施該策略後，您將不得不使用不安全的密碼。 （在實踐中，密碼的存儲方式等等具有更重要的意義，但這不在本文的討論範圍之內）。因此，作為網站/服務的用戶，錯誤的密碼策略會更加糟糕。
如果從組織的角度來看，錯誤的密碼策略要比沒有錯誤的策略糟糕。
沒有密碼策略意味著，可能沒有人考慮過（不是很好，他們沒有考慮安全性，但是還可以...）
但是錯誤的密碼策略意味著：有人考慮過，並提出了這個廢話。這意味著他們可能對安全性一無所知。
最後，如果您可以實施錯誤的密碼策略，那麼您也可以實施良好的密碼策略，因此永遠不會有任何理由為錯誤的密碼策略辯護。僅將策略更改為“密碼必須至少包含8個字符”會大大提高安全性，而且並不難。
現在我想知道什麼對密碼強度更不利。完全沒有密碼策略或圖片中的密碼策略不佳？
您提到的密碼強度要求絕對是弊大於利的，尤其是最大程度的危害。長度。
您的密碼必須：
- 正好八個字符長
我唯一能將其視為合理解決方案的時間是當系統正在運行舊式哈希方案，會截斷除前8個字符以外的所有字符。
例如，Solaris 10用戶帳戶密碼默認使用這種方案，因此，諸如 passwordSup @rsecur☺之類的密碼會被截斷到密碼！ Solaris 11的默認版本沒有此缺點。
在這種情況下
開發人員應致力於向支持密碼長度的更好的哈希例程的遷移。超過8。
直到推出這樣的修復程序，最大長度才是合理的。
在任何其他情況下，這麼短的最大長度肯定是愚蠢的事情。
至少包含一個字母和一個數字。
至少應包括以下一組特殊字符：...
這些是必須的，因為它們的最大長度很短。我確定您可以理解，使用短密碼時需要使用這種原始方法來增加熵。
- 注意：密碼不區分大小寫。
儘管這對於用戶來說很方便（不必擔心大寫鎖定），但從不建議這樣做，因為它總是會降低密碼的熵。在這種情況下，由於最大長度為8個字符，我們不建議這樣做。
此問題應該予以解決，但是現在，由於現有用戶，這將給他們帶來麻煩已經習慣了不安全的配置！
不包含任何空格
我看到的唯一原因是它們是否以純文本形式顯示密碼。 （即，忘記密碼電子郵件或技術支持查找）按大多數標準（糟糕的（不安全的）軟件設計）。
更好的策略是禁止查找並僅允許對其進行更改。實際上，強烈建議使用強（慢）密碼哈希，例如BCrypt，它本質上禁止將查找作為其核心設計的一部分。
- 不是以
開頭嗎？或！
很奇怪，但不是密碼熵的重要殺手。
- 不是以三個相同的字符開頭
嗯，我不太擔心這個字符，但我想知道為什麼他們只看開頭。在8個字符的密碼中，任何地方的3個相同/相鄰字符都比其弱。
- 該密碼必須與您之前的5個密碼不同。
關於此主題，可能有一個專門的安全堆棧交換問題。這是網上銀行和某些其他身份驗證系統的常見做法。
我認為這也與強制性的計劃密碼更改結合在一起。可能的結果是：
但是，如果不是強制性的密碼更改，那麼唯一的問題就是
這不是一個嚴重的問題，但人們對此並不滿意。
這樣的壞策略總比沒有壞。
此策略意味著通常使用“ 123”的用戶現在將擁有更安全的密碼，但仍然很弱，這也意味著現在，使用“ fzFEZ＃5 $ 3rt4564ezezRTyht”（隨機生成）或只是“ cat j_umps over the brown paint wall412”（強熵）之類的人現在的密碼要弱得多。
無論如何，使用弱密碼的用戶在這種情況下也將遭到黑客攻擊（因為這種限制性和弱策略，並且攻擊者能夠設置特定的攻擊規則）。
換句話說，它的安全性要差很多。沒有任何策略，只有使用弱密碼的人才容易受到攻擊。現在每個人都很脆弱。
最好不要使用它。原因如下：
這些策略似乎是由那些不完全了解密碼威脅如何影響您的系統的人想到的。相反，他們只是出於某種原因在“所有框”中打勾。
被說成是他們這樣做的真實原因。有些認證和使用要求其中一些認證和實施（例如衛生部門或某些政府使用）。
沒有一個比顯示的要好，特別是由於8個字符的限制。
所有8個字符的組合都可以使用Titan系列GPU和Ripper在一秒鐘內進行測試。儘管並非所有密碼策略都是有害的（最小長度是好的，一個或多個特殊字符會強制使用更大的破解字母，沒有字典單詞等），但顯示的一個笑話並不是很有趣。總之，是的，這總比沒有要糟，因為它不允許密碼管理器或智能用戶比默認策略更好地保護自己。
策略永遠都不要停止良好的密碼，而只能停止糟糕的密碼。
對於密碼強度，較差的密碼策略或根本沒有密碼策略，最糟糕的是什麼？
這取決於較差的密碼策略。
“您的密碼必須為'letmein'”是一個較差的密碼策略，絕對會比根本沒有策略更糟糕，因為它會阻止任何人輸入正確的密碼。
“您的密碼必須至少包含兩個字符”是一種較差的密碼策略，絕對比根本沒有策略要好，因為它允許任何人使用一個好的密碼並防止某些不好的密碼。
已經有很多好的答案，但是我總是喜歡從稍微不同的角度來看這個問題。當您考慮某種因素將如何影響破解密碼的嘗試時，您必須查看一下它們將如何嘗試進行上述破解。基本上，這可以歸結為兩種方法。蠻力和“智能”猜測，讓我們看看這兩者。
1）蠻力。
這聽起來確實像是。他們嘗試所有可能的密碼。這是嘗試在4位數數字鎖上嘗試從0000到9999的每個引腳的經典方法。此處的關鍵因素是可能的密碼數量以及每次猜測需要多長時間。在這裡，密碼規則可能很棒，由於8位數字的要求，完全可以避免使用暴力破解。如果使用足夠弱的散列，也可能完全是災難性的，並且可以保證在合理的時間內將每個可能的密碼破解給擁有足夠資源的攻擊者。
鑑於這種情況下的規則，強烈建議在後端使用一些相當古老的東西，如果不太可能的話，完全有可能用諸如MD5或SHA1之類的較弱的東西對密碼進行散列處理，並且可能不會加鹽，並且規則可能是災難性的。主要是長度，但也不區分大小寫，這將可能的字符減少了約30％。他們目前有26個字符+ 10個數字+ 28個符號，用於密碼中的64個不同字符。如果它們區分大小寫，它們將有90個字符。
基於一些快速搜索，似乎我們假設一個攻擊者擁有合理數量的資源，並且他們使用的是那些弱哈希值，這看起來非常這些規則可能確實具有災難性，如果現在不存在，則它們肯定有在不久的將來變得災難性的危險，因為計算能力提高了破解速度。長度超過8個字符的密碼可能是安全的，但實際上不允許這樣做。
2）“智能”猜測
假設破解到了這一點，他們給出的密碼規則最終將合併到攻擊者用來生成其可能的密碼的規則中。在這裡，他們的規則雖然不會帶來災難性的後果，但仍然會導致有效密碼的有效性大大降低，因此會加快破解速度。可能還會導致某些非常可預測的密碼，在密碼的開頭/結尾添加符號/數字，或者作為非常可預測的替換的一部分。
如果用戶隨機選擇密碼，則密碼策略會通過限制可能的密碼選擇而使安全性更差，但用戶不會隨機選擇密碼。好的密碼策略的目的應該是促使用戶做出更多選擇，從而在不過度限制密碼空間的情況下選擇更強的密碼。
此策略有好有壞。
長度恰好為8個字符
最小長度合適，最大長度不好。
包括至少一個字母和至少一個數字。
這很好，它促使用戶同時選擇基於字母的部分和數字基於組件。
密碼不區分大小寫。
這樣可以顯著減小密碼集的大小。另一方面，除非是強制使用，否則大多數人不會使用大寫字母；當他們使用大寫字母時，他們往往會以可預見的方式使用大寫字母。
至少包含一個特殊字符
還是很好，它迫使密碼創建者做出其他選擇。
禁止使用空格和規則？和！
我懷疑這些設置是否會有所不同。
在開始處禁止重複出現的字符
可能是一件好事，這意味著用戶不能只用單個字母的重複填充密碼。
總的來說，如果您有笨拙的用戶，那麼此策略可能總比沒有好，但是如果您的用戶有一個不錯的密碼的提示，弊大於利。
到目前為止，我要走的路與所有其他答案都不同……並且說在某個時候，這沒關係。該算法對FAR的影響遠大於密碼規則。
例如，有人可能使用ROT13，這很糟糕。
或者，使用MD5會更好一些。
也許他們然後加鹽。
也許使用crypt（）。也許再添加胡椒。
不過，GPGUP可以在一秒鐘內燒掉數十億個密碼哈希。那麼，還有什麼呢？
SHA-2-512帶有128位鹽。更好的是，GPGPU可以做很多事情。
更改為bcrypt。好多了。現在，我們已經超越了單個GPGPU可以快速將它們全部燒毀的地步。
更改為PBKDF2，加滿鹽和胡椒粉並進行10,000發。
要加密，現在密碼很短。 “無法破解”，因為算法太慢了。
下面是一個表，可能會幫助解釋它：
嘗試次數/秒NTLM 350,000,000,000 MD5 180,000,000,000 SHA1 63,000,000,000 SHA512Crypt 364,000 Bcrypt 71,000 因此，用bcrypt散列的cr腳密碼比使用MD5散列的密碼好。
這實際上取決於最終用戶。我的看法是，如果您作為公司/網站的用戶如果某人的帳戶被盜，不承擔責任，那麼最好放棄正式的密碼政策，至少是限制性的密碼政策。
我一直認為用戶應該對自己的安全負責，因為他們了解弱密碼之類的含義。
當然，最後一部分是密鑰，好像用戶不知道該怎麼做一樣，您應該強制他們使用比他們想要使用的密碼更安全的密碼。但是，如您的示例所示，密碼策略僅應鼓勵使用更安全的密碼，而不應限制密碼強度。
我個人在我的大學網站上碰到過這個問題。我相當長的字母數字密碼不滿足那裡的密碼政策，因此不鼓勵使用某些（但不是全部：/）特殊字符。結果是一個故意較弱的密碼，因為對我來說，記住一個我沒有故意記入內存的密碼更加困難。
尤其是在那種情況下，我懷疑“密碼策略”更多是避免在後端進行某些字符串解析/清理的藉口，而不是鼓勵更好的安全性的合法方法。
>最後，如果實施了密碼策略，則該密碼策略將隨時間而變化。也就是說，在1990年代被認為是安全密碼的情況不再如此，在2016年，那時普通消費者可以利用雲計算或GPU集群為您的密碼提供數量巨大且不斷增長的計算機功能。 >