完全没有考虑它，我只想说我应该允许每个角色。无论如何它都会被散列，我不想限制想要创建强密码的人。
但是，仔细想想，有很多角色我不知道它们会对事物产生什么影响。外来字符、ascii 符号等来命名一对。
我试着用谷歌搜索，但我找不到任何关于人们做什么的明确标准。即使是大多数专业组织似乎也不知道。对于许多网站来说，完全禁止特殊字符似乎是一种常见的做法，这很愚蠢，而不是我想要做的。
无论如何，对于长度、允许的字符等是否有任何标准建议？
我不确定这是否重要，但我将使用带有 C# 的 ASP.NET
PhoenixRedeemer
问问题
6106 次
9 回答
9
在有限的设备（手机、控制台等）上输入密码时，非 ASCII 字符肯定会让事情变得更难——但通常并非不可能。可以说，如果用户想要这样做，您应该让他们这样做。做一件合理且一致的事情很容易——例如，在散列之前用 UTF-8 编码。如果某些输入设备将字符作为组合发送（例如 e + 重音而不是“e 重音”），您只会遇到困难 - 但我怀疑这在现实生活中不会发生。（你可以自己分解所有东西，但是对于边缘情况来说这会很麻烦。）
但是，我会将其限制为可打印的字符。将标签、表单提要等放入密码中确实是在自找麻烦。
于 2008-12-21T14:04:52.720 回答
3
不是专家，但我讨厌我选择的角色，而不是那些奇怪的角色被拒绝。所以，我想我同意你的直觉。
于 2008-12-21T14:00:24.790 回答
3
从根本上说，应该允许大多数 unicode 类字符。但是请跳过控制字符（例如，除了空格之外的 0-31）、字节顺序标记（0xfffe 和 oxfeff）。此外，您希望首先规范化表示以摆脱由不同表示引起的问题。尽管您可能会针对似乎难以输入的字符发出警告，但用户会自行防范。
于 2008-12-21T15:18:39.780 回答
3
简短的回答：允许尽可能多的系统支持它可以支持。现在真的没有理由不使用完整的 unicode 支持来进行文本输入，包括密码。我认为你不需要担心字符问题，只要它们是按字面意思处理的（但我不是这个领域的专家——小心 sql 注入）。
我对那些对密码施加限制的网站很恼火……任何形式的限制。我喜欢那些会告诉你密码有多强的网站，并建议你让它变得更强，但强迫用户输入至少 8 个字符，或者同时要求字母和数字等，这简直令人沮丧。
如果您需要最大字段大小（例如用于存储在数据库中），请尝试使其足够大以容纳人们手动输入的任何内容。确实没有太大的密码字段，因为总是有可能使用自动生成的强密码，但 64 到 128 个字符肯定就足够了。
于 2008-12-21T16:00:02.240 回答
2
请记住：当您存储密码时，所有密码都应使用单向算法（如 sha1 的 md5）进行加密。由于这些算法总是产生十六进制数字，因此您无需担心 SQL 注入或类似的事情。
所以，只要你能 md5 或 sha1 一个字符，就应该被接受。
于 2008-12-21T16:30:36.903 回答
1
如果您正在谈论防止 SQL 注入类型的攻击，那么确保您的代码执行它应该做的事情可能是一个更好的主意，而不是依赖于限制输入以使问题变得更容易。
对于非 ascii 字符，如果您的输入可以正确表示为二进制字符串（而不是text），我认为这不是一个更困难的问题，然后将其传递给您的哈希函数或密钥生成器等。
于 2008-12-21T14:24:32.337 回答
1
为“让用户包括其界面允许他们输入的任何和所有字符”添加另一票。我什至不会禁止制表符或控制字符。您的软件能够接受任意字节串并对其进行散列，因此接受任意字节串作为密码。否则会减少攻击者在蛮力或字典攻击中必须搜索的空间。
（当然，即使你允许一切，99% 的用户仍然会使用他们宠物的名字作为他们的密码......）
于 2008-12-21T16:58:21.170 回答
-2
最终，您可能必须在发送给用户的确认电子邮件中打印出清晰的密码。
PS：可能还会考虑电子邮件中的编码问题，如果它不是标准的 ascii（例如日文字符），用户可能不会收到正确格式的电子邮件，或者由于字体而无法在另一个系统上阅读它没有被安装。
所有这些都在“可打印”的 ascii 字符范围内。
于 2009-01-27T09:17:16.360 回答