我应该在密码中支持Unicode吗？
我想让我的用户使用Unicode作为他们的密码。
不过，我看到很多网站不支持（例如Gmail，Hotmail）。
所以我想知道是否有一些我可以忽略的技术或可用性问题。
我想如果有什么必须是一个可用性问题，因为默认情况下，.NET接受Unicode，如果Hotmail – 呃，新的Live邮件 – build立在这个基础上，我不明白为什么他们会限制它。
有没有人遇到类似的问题？
我相信没有技术问题，但也许gmail和hotmail不是故意支持的。 这类网站有广泛的受众群体，应该可以从任何地方访问。
假设用户有日文密码，但他正在旅行，去网吧，没有日语支持，用户将无法login。
另外一个问题是分析密码的复杂性，确保用户不用英文input一个常用的单词并不难，但是用中文/俄文/泰文怎么办？ 添加更多语言时分析密码的复杂性要困难得多。
因此，如果您希望您的系统可以访问，最好确保用户能够在各种设备/操作系统/环境中input密码，所以最常用符号的字母数字密码（ !<>"#$%&等..）是一个很好的字符可用的地方到处都是。
一般来说，我强烈支持不限制密码中允许的字符types。 但是，请记住，您必须将某些内容与可能是密码或哈希值的内容进行比较。 在前一种情况下，你必须确保比较正确完成，这比Unicode单独使用Unicode要复杂得多。 在后一种情况下，您必须确保每次input时都进行哈希运算。 规范化forms在这里可能有帮助，或者是一个诅咒，取决于谁适用。
例如，在我正在处理的应用程序中，我正在使用一个散列来对事先规范化的密码进行UTF-8转换，以清除组合字符等的潜在问题。
用户可能面临的最大问题是他们无法在某些地方input，如在另一个键盘布局上。 对于我的其中一个密码，情况已经如此，但从未成为问题。 毕竟，这是用户在select密码时所做的决定，而不是应用程序代表用户做出的决定。 我怀疑有谁在他们的密码中愉快地使用任意的Unicode并且没有考虑到在使用另一个键盘布局时可能出现的问题。 （尽pipe这可能是networking服务的一个问题。
但有些情况下，Unicode是正确的禁止。 TrueCrypt就是这样的一个例子，它强制使用美式键盘布局作为开机密码（用于全卷encryption）。 那里没有其他布局，因此Unicode或任何其他键盘布局只会产生问题。
但是，这并不能解释为什么他们禁止Unicode在正常的密码。 警告可能是好的，但彻底禁止在我眼中是错误的。
所以我想知道是否有一些我可以忽略的技术或可用性问题。
使用HTTP基本validation的非ASCII密码（和用户名）存在技术问题。 据我所知，您提到的网站通常不使用基本身份validation，但它可能是系统的宿醉。
HTTP基本authentication标准定义了base64编码的username:password标记。 这意味着如果你在用户名或密码中有冒号，结果是不明确的。 此外，base64解码令牌只给你字节，没有方向如何将这些字节转换为字符。 你猜怎么着？ 不同的浏览器使用不同的编码来做到这一点。
-
Opera和Chrome使用UTF-8。
-
IE使用客户端系统的默认代码页（当然从来没有UTF-8），并使用Windows标准损坏不符合它的字符。尝试查找一个看起来有点像它的字符，或者可能不是（谁Cares）algorithm。
-
Safari使用ISO-8859-1，并且在用户名或密码中包含不适合的字符时，默默拒绝发送任何validation令牌。
-
Mozilla采用代码点的最低8位（与ISO-8859-1类似，但更多）。 看到错误41489的曲折讨论没有结果或进展。
因此，如果您允许使用非ASCII用户名或密码，那么基本身份validation过程将最多变得复杂且不一致，用户不知道为什么它们在使用不同的计算机或浏览器时随机工作或失败。
否。将密码限制为ASCII字符。
当您input密码时，会显示项目符号以隐藏密码。
但是，当你input日语和其他语言，你必须经过一个input法，将击键转换成所需的字符。 这要求你看看字符是什么。
如果您必须进行编程匹配，Unicode会很糟糕。 “减号”和“破折号”看起来是一样的，但可能是单独的代码。 “有一个有趣的代字符”可能是一个字母，或一个变音符号和一个字母。
如果人们使用不同的编码方法，那么即使密码看起来相同，他们的密码也可能不匹配。 参见omg-ponies aka人类=史诗失败 。
你可以规范化，但会发生什么情况：
- 规范化规则改变
- 你有一些用户在他们的密码中有变音符号
- 你有一些用户在他们的密码组合字母
- 密码被哈希，所以你不能改变密码
猜猜看 – 你需要强制一些用户重置密码。
我在所有的Web应用程序中都支持Unicode密码。 如果使用最近的浏览器，访问者可以使用他们首选或本地脚本中的任何代码点。
为了增强安全性，我存储了一个腌制散列，而不是使用可逆encryption。
重要的是在将字节序列添加到哈希之前正确地对密码string进行规范化和编码（我更喜欢utf-8的endian独立性）。
我相信这些网站的多语种同行确实支持unicode。 这听起来像是一个用户需求问题，而不是技术挑战。
我不会感到惊讶，如果有一个技术问题，服务器不是确定的客户端发送密码的编码。
但是，我猜想，主要是以日本，中国或俄罗斯为母语的网站的用户将使用常用的非ASCII字符集（Big5，EUC-KR，koi8等）作为密码。 也许你可以研究他们正在做什么来处理使用任何非Unicode的东西的旧的Web客户端。
好主意。
使密码更强大，给用户更多的自由。 它已经由Windows（至lessWin 2000），Active Directory和LDAP，Novell（至less自2004年以来）完成，
有些客户需要它（ http://mailman.mit.edu/pipermail/kerberos/2008-July/013923.html ），甚至有关于如何做到这一点的标准（ http://tools.ietf.org/ html / rfc4013 ）。
使用HTML 5，可以将字体发送给用户，您可以在系统上集成一个可视键盘，这样用户就可以使用您的语言，
提示：使用Deja Vu字体 ，并使用FontForge对其进行修改，以便缩小尺寸，然后使用可视的JavaScript键盘，使其成为可能;）
看这里 ，这是一个项目，我做的伎俩。
