i18n - 國際化和密碼複雜性規則

Question

我目前正致力於產品的國際化，並且出現了一個問題。該問題圍繞非拉丁語言和複雜字符集的國家的密碼複雜度要求展開。

應用程序使用aspnet成員資格進行用戶和密碼管理，但這可能是另一個問題。目前我們的應用程序已經設置了適合A-Z，0-9和組成密碼的特殊字符的設置和代碼，但這些將很可能需要擴展以應對其他文化。

我一直在尋找這方面的指導和最佳實踐，至今沒有太多的喜悅。 last post on this SO question涉及這個問題，但並沒有真正提供任何指導。

Answer 1

技術人員在我們公司的一個分支，在中國國外接觸後，我們發現了大頭，他們使用需要登錄的系統時，往往會堅持到標準的ASCII字符集的用戶名和密碼這些原因。

中文鍵盤一般都有QWERTY和漢字一起設置，用戶可以在中文和ASCII輸入法之間切換，輕鬆登錄到系統。現在，我們將離開我們的系統，並監控添加的其他文化，處理可能出現的任何特殊情況。

對中國輸入法的更多信息，請Wikipedia - Chinese input methods for computers

Answer 2

取決於您要執行的操作。字典檢查和模式識別應該以任何編碼和語言工作。如果你想強制執行流行但任意規則的「大寫，小寫和數字混合」，那麼，是的，你可能需要找到A）可以確定任何語言的案例和數字的庫或API，或者B）創建一個愚蠢的大型數據庫來自己映射這些信息。

雖然這種複雜性規則是黑客行爲。愚蠢的人會創建愚蠢的密碼，無論你強制執行什麼樣的複雜性規則。密碼安全的最佳實踐是確保用戶必須選擇一個不像其可能的猜測密碼，因此字典檢查（不要忘記在密碼創建頁面上添加所有單詞以及與密碼相關的所有單詞條目，應用程序或其環境，以及所有可用的用戶特定信息，例如出生日期和婚前姓名）和模式匹配（abc123）。

其實我已經看到了很多，其中「abc123.-」或類似的東西被用來作爲root密碼，因爲沒有人可以arsed想出能夠滿足複雜條件的真實密碼的情況下。

Answer 3

很大程度上取決於訪問需要的安全性。對於高安全性而言，密碼方法並不實際，而某種生物特徵（指紋？）或雙因素（SKey？）方法可能會更好，特別是與數字PIN相結合時。

這是因爲它不是真正的實際執行上非西方語言的密碼字典或複雜性分析。具體做法是：

• 許多語言不大寫和小寫
• 某些語言中兩個，三個或四個字節編碼字符區分
• 沒有理由以引入在密碼數字或標點字符對於擁有大量表意文字（如簡體中國）的文化
• 了大量的語言字典維護可能是不切實際

對於簡單的Web如果您將網站的非西方語言版本交付給瀏覽器，則可能建議對密碼執行更強的檢查。