這聽起來很像Fencepost Security。想像一下，您正在運行的設施周圍有500英尺高的鏈節圍欄。將圍欄高到3,000英尺，安全性將提高多少？沒有-因為任何試圖進入的人都不會爬500英尺；他們會在下面挖洞，打個洞等。

同樣，您有一個密碼，例如20個隨機字母數字字符。那是62 ^ 20的可能性。您正在考慮將其更改為20個隨機unicode字符。這樣就增加了更大的可能性空間，除了強行強制使用20個字符的隨機密碼並不是要如何妥協之外。

從安全角度來看，這是個好主意。包含unicode字符的密碼比包含相同長度ASCII字符的密碼更難於暴力破解。即使比較字節長度而不是字符長度，這也會成立，因為Unicode使用最高有效位，而ASCII不使用最高有效位。 。我認為，如果您到處都使用Unicode密碼，則會遇到多個站點，在這些站點上登錄會遇到問題，因為開發人員未正確實現對密碼的Unicode支持。

忽略安全性的隱喻論證是一個基本的熵問題。 8個字符的unicode密碼比8個字符的ASCII密碼更安全，但比64個字符的ASCII密碼更不安全。最重要的是，如果您需要手動輸入密碼，則隨機Unicode可能會使您的生活陷入困境。

但是在極端情況下，您需要使用在主動執行unicode的同時強制支持最大密碼長度限制（再次忽略此密碼通常表示存在其他安全漏洞），為此有一個參數。

我能想到的在密碼中使用Unicode字符的唯一正當理由是，如果某個特定站點的密碼中的字符數（而非字節數）受到限制（例如以前擁有的最多10個字符），這樣一兩天就可以輕鬆猜到。在這種情況下，您可以在要求站點所有者遵守 NIST 800-63-3和消除長度限制（並適當地進行哈希處理，這樣就不必擔心密碼存儲了。）

我還想在這裡糾正一個誤解：

Unicode使用最高有效位，而ASCII使用最高有效位

雖然對於普通ASCII是正確的，但是某些密碼管理器（例如KeePass）可以在密碼生成中使用的擴展ASCII使用每個字節的每一位，因此具有較高的熵甚至比Unicode的密度更高，Unicode仍具有某種結構來指示同一字符的以下幾個字節（請注意， 就是Unicode中的無效字節序列）。

因為一個將您限制為短密碼的網站可能甚至無法正確地散列其密碼（導致Unicode密碼失敗或與密碼一起存儲）。錯誤的編碼），您幾乎應該永遠不要浪費時間去打擾Unicode密碼，因為當您對有趣的字符分心（以及由於密碼存儲不正確而不得不重置密碼的事實）時，攻擊者可能會猜測您的（安全性）問題，或使用巧克力密碼術來訪問您的帳戶。

在某些情況下，這種方法可能降低您的整體安全性，而不是提高安全性。

信息安全性由三個屬性組成：機密性，完整性和可用性（ CIA三合會）。通過只關註一個，您可以輕鬆地忽略另一個的重要性。

密碼的機密性是通過熵原理實現的：您的密碼有多“不宜使用”？通常用蠻力猜測空間的大小來度量，用2或位的冪表示。蠻力攻擊者只有這麼大的猜測能力。通過選擇更長的密碼來增加這種熵，您可以超越任何已知或預測的猜測能力。使熵超過80位（或選擇您的值）將使密碼甚至無法進入民族國家行為體。不管上面的描述是否過於簡單，關鍵是要超越“超出範圍”並不會對您的安全性產生重大影響。如果通過使用10個Unicode字符或17個ASCII字符來實現所需的熵，則與安全性無關。

可用性表示“我可以在需要時獲取數據嗎？”如果您使用完整的Unicode字符集，則冒著以下風險：不支持Unicode的各種站點，錯誤實現Unicode的瀏覽器或OS或在幕後隱式將Unicode轉換為ASCII的站點。造成的混亂會增加限制您將來訪問數據的風險。這表示將來的可用性可能會降低。

通常，攻擊者強行強行使用您的80位密碼的可能性不及遇到編碼不良，無法處理Unicode的網站的可能性高正確地。因此，您的整體安全性可能會降低而不是提高。

當然，許多站點都有密碼長度和其他限制，這些限制也極大地限制了密碼的熵。在這些情況下，假設沒有其他隱藏的缺陷，使用完整的Unicode集可能會增加密碼的熵。因此，在這些站點上，您可能會提高安全性；但實際上不可能從外部得知站點是否正確處理了您的密碼數據。

這可能不是直接的答案，但是如果密碼僅以數字方式保存，那麼您應該問自己為什麼要生成一個 password 而不是一個字節數組。一旦您將整個內容看成簡單的字節，問題就不再適用。

長度>在與密碼有關的所有事情中的複雜性。

關於您的問題的RFC：代表用戶名和密碼的國際化字符串的準備，執行和比較，其摘要為：

本文檔介紹了更新的方法用於處理代表用戶名和密碼的Unicode字符串。先前的方法稱為SASLprep（RFC 4013），它基於Stringprep（RFC 3454）。本文檔中指定的方法為處理國際化的用戶名和密碼提供了一種更可持續的方法。

如果您閱讀法語，也可以在此處找到很好的解釋： http ：//www.bortzmeyer.org/8265.html。

RFC的第8節專門涉及使用“任何” Unicode字符的密碼安全性，其中包括以下部分：

• 8.1。密碼/密碼強度
• 8.2。密碼/密碼比較
• 8.3。標識符比較
• 8.4。重複使用PRECIS
• 8.5。重用Unicode

除了其他很好的答案外，我只想指出使用完整的Unicode密碼集在管道中會出什麼錯。

假設您隨機使用一個或多或少有效的UTF-8字符串，

• 在基本多語言平面的中間有一些解釋為換行符的字符，例如 U + 2029段落分隔符 。您可能不能在普通的 <input> 字段中輸入它們。
• 這兩種空格字符可能會或可能不會被語言的 trim（）方法
• 如果您碰巧使用了替代字符（U + D800-U + DFFF），非字符，例如 U + FDD0，專用字符或未分配的字符（儘管有效的UTF-8序列），基本上未定義任何給定工具集的行為（剝離，替換，拒絕，不執行任何操作或以下各項的任意組合）
• ，如果您碰巧要添加變音符號，則任何正在進行的工具都可能會將其更改為 NFC或NKD表示形式，並更改了密碼中的字節。
• 那隻是從我的頭上。我敢肯定，如果從整個Unicode範圍中選擇密碼，我會忘記很多其他可能的問題。

因此，類似於@JohnDeters的建議，這可能是一個壞主意，因為這樣一來，文本處理的可移動部分將無法提供更大的源空間。

對安全至關重要的是密碼的熵-密碼中有多少位實際信息。

問題的另一方面是，記住密碼和鍵入密碼有多困難。想像一下，您嘗試在iPhone上鍵入密碼時，您發現自己不能（我沒有檢查鍵入任意Unicode字符的難度）。或者您意識到正確地100％輸入非常非常困難。或者，這可能需要您花很多時間-我的密碼可能具有相同的熵和更多的字符，但鍵入速度卻快一倍。您需要四次嘗試才能做到正確，而我的第一次是正確的。

其他人充分說明了使用這些密碼的服務無法正確實現Unicode的風險。我將添加今天 今天提供的服務可能會明天停止這樣做，但否則我將跳過該主題。

我想說的一個要素想這裡必須考慮的一個問題是：要達到某個安全級別，密碼需要多長時間？假設我們希望我們的密碼與128位加密密鑰一樣強（對於大多數網站密碼來說，這可能是過高的；我建議使用80位）。如果您堅持使用隨機ASCII密碼，則從〜95個可打印ASCII字符中抽取的19個字符的密碼將達到該級別。 （數學：一組大約100個元素約為6.6位/元素（因為log2（10）≈3.3，而log2（100）是元素的兩倍），即128÷6.6≈19.4。因此19個ASCII字符實際上約為126位，而不是128位，而是meh。）

Unicode當前定義了大約130,000個代碼點，我們可以將其近似為2 ^ 17。這意味著要達到128位級別，您需要7個Unicode代碼點（128÷17≈7.5，所以7個代碼點僅約119位，但還是這樣）。

對於80位安全性級別，對於大多數網站，我認為比較明智，它是12個ASCII字符和5個Unicode代碼點。

您是否願意承受巨大的可用性並冒網站錯誤的風險，以便您可以擁有5個或9個7個字符的密碼，而不是12個或19個字符？我只是不認為這是值得的。

好吧，Unicode只是一個超過130000個字符的列表。 UTF-8是最常見的編碼，它根據一個規則集，將一個大數字並將其“轉換”為以256為基數的數字（或更準確地說，該規則在二進制八位字節中更有意義）。因此，如果您想使用utf-8編碼，則會受到許多規則的約束，從而有效地降低了可能需要的隨機性。而且我不知道如何使用整個Unicode解釋。

如果您不關心可打印字符，則可以考慮整個ASCII（或更可取的是8位擴展名），但是那一點，為什麼還要打擾字符解釋標準呢？那麼，您不能簡單地使用一些簡單的無格式隨機二進制結構嗎？

即使您僅使用數字存儲，我也不希望成為需要在其中輸入內容並且不認識（和（。（。提示：它們是雙精度和單精度-

使用此寬度敏感的示例，如其他答案中所指出的那樣，您希望它們支持這些功能-根據此處設置的SQL排序規則，密碼不正確！

不。您想增加指數函數的基數，同時又要冒很多事情的危險（例如，無法鍵入特殊字符的設備等）。計算unicode密碼的熵，並使ascii密碼更長，直到具有更大的熵。

az 單獨為26 ^（長度）。假設您使用Unicode獲得 256 ^（length）以及每個字符2個字節。然後，您可以在某個地方找到 26 ^（ascii_length）> 256 ^（2 * unicodelength）的收支平衡。選擇此長度作為 ascii_length ，您仍然可以寫下密碼並具有相同的安全性。

如果該站點不支持長密碼（對此感到羞恥），我會懷疑他們也不能保證良好的unicode支持。下次他們升級某些內部庫時，您可能會被鎖定。那麼，為什麼要在那裡冒險呢？還有一個很難向用戶支持解釋的問題，它幾乎不知道unicode的含義。

生成隨機Unicode密碼不是一個好主意，因為生成的密碼可能對用戶不可讀。但是問題的內容是關於使用Unicode密碼的，這是一個好主意，並由NIST 800-63-3部分 5.1.1.2記憶秘密驗證者建議：

驗證者必須要求用戶選擇的存儲秘密的長度至少為8個字符。驗證者應允許用戶選擇的記憶秘密，其長度至少為64個字符。在存儲的機密中，應接受所有印刷ASCII [RFC 20]字符以及空格字符。

出於上述長度要求的目的，每個Unicode代碼點也應計為一個字符。

繼續：

如果存儲的機密中接受Unicode字符，則驗證者應使用Unicode標準附件15第12.1節中定義的NFKC或NFKD歸一化對穩定字符串應用歸一化過程。

總結：Unicode的使用增加了熵，並使不精通英語的用戶的生活更加輕鬆。