KL9*_*L90 45 passwords unicode
我想允许我的用户使用Unicode作为他们的密码.
但是我看到很多网站都不支持(例如Gmail,Hotmail).
所以我想知道是否存在一些我忽视的技术或可用性问题.
我在想它是否必须是一个可用性问题,因为默认情况下.NET接受Unicode,如果Hotmail - 呃,新的Live邮件 - 建立在它上面,我不明白为什么他们会限制它.
有没有人遇到类似的问题？
Rag*_*geZ 38
我确信没有技术问题,但gmail和hotmail可能不会故意支持.这类网站拥有广泛的受众群体,应该可以从任何地方访问.
让我们假设用户有一个日语密码,但他正在旅行并去网吧,没有日语支持,用户将无法登录.
另一个问题是分析密码的复杂性,确保用户没有用英语输入常用单词并不是那么难以用中文/俄文/泰文输入.在添加更多语言时,分析密码的复杂性要困难得多.
因此,如果您希望系统可以访问,最好确保用户能够在各种设备/操作系统/环境中键入密码,因此带有最常见符号(!<>"#$%&等等)的字母数字密码是各种各样的好人物.
Joe*_*oey 24
一般来说,我强烈建议不要限制密码中允许使用哪种字符.但是,请记住,您必须将某些内容与存储的内容(可能是密码或哈希值)进行比较.在前一种情况下,你必须确保正确地进行比较,这比使用Unicode要复杂得多; 在后一种情况下,无论何时输入,您都必须确保完全相同.规范化形式可能在这里有所帮助或者是一种诅咒,具体取决于谁应用它们.
例如,在我正在处理的应用程序中,我使用的是密码的UTF-8转换的哈希值,该密码已事先规范化以清除组合字符等的潜在问题.
用户可能面临的最大问题是他们无法在某些地方输入它,例如在另一个键盘布局上.对于我的一个密码已经是这种情况,但到目前为止从来都不是问题.毕竟,这是用户在选择密码时必须做出的决定,而不是应用程序应该代表用户做出的决定.我怀疑是否有用户在他们的密码中愉快地使用任意Unicode,而没有想到使用其他键盘布局时可能出现的问题.(但这可能是基于Web的服务的问题,而不是其他任何问题.)
但是有些情况下,Unicode被正确禁止.一个这样的例子是TrueCrypt,它强制使用美国键盘布局作为启动时密码(用于全卷加密).那里没有其他布局,因此Unicode或任何其他键盘布局只会产生问题.
但是,这并不能解释为什么他们禁止在普通密码中使用Unicode.警告可能不错,但在我看来,彻底禁止是错误的.
bob*_*nce 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,但更加破碎).请参阅错误41489进行曲折讨论,没有结果或进展.
因此,如果您允许使用非ASCII用户名或密码,那么基本身份验证过程最好是复杂且不一致的,用户会想知道它们在使用不同的计算机或浏览器时随机工作或失败的原因.
| 归档时间： |
|
| 查看次数： |
12422 次 |
| 最近记录： |