我想允许我的用户使用Unicode作为密码。
但是我发现有很多网站不支持（例如Gmail，Hotmail）。
所以我想知道是否存在一些我忽略的技术或可用性问题。
我在想它是否一定是一个可用性问题，因为默认情况下.NET接受Unicode，如果Hotmail - 呃，新的Live邮件 - 建立在它上面，我不明白为什么他们会限制它
有没有人遇到过类似的问题？
答案 0 :(得分：37)
我确信没有技术问题，但gmail和hotmail可能不会故意支持。这类网站拥有广泛的受众群体，应该可以从任何地方访问。
让我们假设用户有一个日语密码，但他正在旅行并去网吧，没有日语支持，用户将无法登录。
另一个问题是分析密码的复杂性，确保用户没有用英语输入常用词，但用中文/俄文/泰文输入的内容并不困难。在添加更多语言时，分析密码的复杂性要困难得多。
因此，如果您希望系统可以访问，最好确保用户能够在各种设备/操作系统/环境中键入密码，因此使用最常见符号的字母数字密码（{{ 1}}等...）是各种各样的好字符集。
答案 1 :(得分：24)
一般来说，我强烈建议不要限制密码中允许使用哪种字符。但是，请记住，您必须将某些内容与存储的内容（可能是密码或哈希值）进行比较。在前一种情况下，你必须确保正确地进行比较，这比使用Unicode要复杂得多;在后一种情况下，您必须确保在输入时完全相同。规范化形式可能会有所帮助，也可能是一种诅咒，具体取决于谁应用它们。
例如，在我正在处理的应用程序中，我使用的是对密码的UTF-8转换的哈希值，该密码已事先规范化以清除组合字符等的潜在问题。
用户可能面临的最大问题是他们无法在某些地方输入，例如在其他键盘布局上。对于我的一个密码已经是这种情况，但到目前为止从来都不是问题。毕竟，这是用户在选择密码时必须做出的决定，而不是应用程序应该代表用户做出的决定。我怀疑是否有用户在他们的密码中愉快地使用任意Unicode，而没有想到使用其他键盘布局时可能出现的问题。 （但这可能是基于网络的服务的问题，而不是其他任何问题。）
但是有些情况下，Unicode被严格禁止。一个这样的例子是TrueCrypt，它强制使用美国键盘布局作为启动时密码（用于全卷加密）。那里没有其他布局，因此Unicode或任何其他键盘布局只会产生问题。
但是，这并不能解释为什么他们禁止在普通密码中使用Unicode。警告可能不错，但我眼中的彻底禁止是错误的。
答案 2 :(得分：20)
所以我想知道是否存在一些我忽略的技术或可用性问题。
使用HTTP基本身份验证时，非ASCII密码（以及用户名）存在技术问题。据我所知，您提到的网站通常不使用基本身份验证，但它可能是系统中的宿醉。
HTTP基本身份验证标准定义了base64编码的username:password令牌。这意味着如果您在用户名或密码中有冒号，则结果不明确。此外，base64解码令牌只给你字节，没有指示如何将这些字节转换为字符。你猜怎么着？不同的浏览器使用不同的编码来完成它。
Opera和Chrome使用UTF-8。
IE使用客户端系统的默认代码页（当然不是UTF-8）并使用Windows标准修改不适合它的字符尝试查找看起来有点像的字符，或者也许不是（谁关心）算法。
Safari使用ISO-8859-1，当用户名或密码包含不适合的字符时，它会默默地拒绝发送任何身份验证令牌。
Mozilla占用代码点的最低8位（类似于ISO-8859-1，但更加破碎）。请参阅bug 41489进行曲折讨论，但没有结果或进展。
因此，如果您允许使用非ASCII用户名或密码，那么基本身份验证过程将最复杂且不一致，用户会想知道为什么它在使用不同的计算机或浏览器时会随机工作或失败。
答案 3 :(得分：7)
没有。将密码限制为ASCII字符。
输入密码时，会显示项目符号以隐藏密码。
但是当您输入日语和其他语言时，您必须通过输入法，将键击转换为所需的字符。这需要您查看字符是什么。
答案 4 :(得分：4)
如果人们使用不同的编码方法，那么即使密码看起来相同，他们的密码也可能不匹配。请参阅omg-ponies aka humanity=epic fail。
您可以规范化，但会发生以下情况：
猜猜是什么 - 您需要强制重置某些用户的密码。
答案 5 :(得分：2)
我支持所有Web应用程序中的Unicode密码。如果使用最近的浏览器，访问者可以使用其首选或本机脚本中的任何代码点。
为了增强安全性，我存储盐渍哈希而不是使用可逆加密。
重要的是在将字节序列添加到散列之前正确地规范化和编码密码字符串（我更喜欢UTF-8以实现字节序独立）。
答案 6 :(得分：1)
好主意。
使密码更强，为用户提供更多自由。 它已经由Windows（至少从Win 2000开始），Active Directory和LDAP，Novell（至少从2004年开始）
完成有些客户想要它（http://mailman.mit.edu/pipermail/kerberos/2008-July/013923.html），甚至还有关于如何正确行事的标准（http://tools.ietf.org/html/rfc4013）。
答案 7 :(得分：0)
我确信这些网站的多语种版本确实支持unicode。这听起来像是用户需求问题，而不是技术挑战。
答案 8 :(得分：0)
如果服务器出现技术问题而不确定客户端是否正在发送密码，我不会感到惊讶。
但是，我猜想，主要讲日语，中文或俄语的受众群体的网站会使用常用的非ASCII字符集（Big5，EUC-KR，koi8等）作为密码。也许您可以使用任何非Unicode内容来研究他们正在做些什么来应对旧的Web客户端。
答案 9 :(得分：0)
使用HTML 5，能够向用户发送字体，您可以在系统上集成可视键盘，这样用户就可以使用您的语言，
提示：使用Deja Vu font，然后使用FontForge对其进行修改，以便您可以将其缩小，然后使用可视化的javascript键盘，您可以使其成为可能;）
Look here，这是我完成这项工作的项目。