密码中允许使用哪些字符的最佳规则是什么？

Question

在没有考虑它的情况下，我只想说我应该允许每一个角色。在任何情况下都会受到影响，我不想限制想要创建强密码的人。

然而，考虑更多，有很多人物，我不知道他们对事物有什么影响。外国字符，ascii符号等等，以命名一对。

我试过谷歌，但我找不到人们做什么的明确标准。甚至大多数专业组织似乎都不知道。对于许多网站而言，完全不允许使用特殊字符似乎是一种常见做法，这只是愚蠢而不是我想做的事情。

无论如何，是否有关于长度，允许字符等的标准建议？

我不确定它是否重要，但我将使用ASP.NET w / C＃

Answer 1

密码中通常允许使用任何可打印的非空白ASCII字符（介于33​​和126之间）。许多安全专业人员（以及SO评论者）建议使用passphrase代替密码，因此您必须允许空格。争论的焦点是由于它们的长度，并且因为短语不在字典中，所以密码短语比密码更难破解。 （密码也可以更容易记住，因此合法用户不必将其记录在显示器上的便利贴上。）

有些strong password generators使用哈希，所以我对长度（512或1024）设置了非常高的限制，只是为了包容。今天的密码生成器通常会产生32-128个字符的字符串，但谁知道未来几年将使用什么样的哈希值。

Answer 2

在有限的设备（手机，游戏机等）上输入密码时，非ASCII字符肯定会让事情变得更难 - 但通常并非不可能。可以说，如果用户想要这样做，你应该让他们。这很容易做一个合理和一致的事情 - 例如，在散列之前用UTF-8编码。如果某些输入设备将字符作为一个组合发送（例如e +急性重音而不是“e锐”），你只会遇到困难 - 但我怀疑在现实生活中不会发生这种情况。 （你可以自己分解所有东西，但要找到一个边缘案例会有很多麻烦。）

但是，我将其限制为可打印的字符。将标签，表单提要等放入密码确实 要求麻烦。

Answer 3

不是专家，但我讨厌我选择的角色，而不是那些奇怪的被拒绝。所以，我认为我同意你的直觉。

Answer 4

简短回答：尽可能多地支持它所支持的系统支持。现在，没有理由不使用完整的unicode支持文本输入，包括密码。我不认为你需要担心字符问题，只要它们按字面处理（但我不是这个领域的专业人员 - 谨防sql注入）。

我对那些对密码施加限制的网站感到很恼火...... 任何类型的限制。我喜欢会告诉你密码有多强的网站，并建议你加强密码，但强迫用户键入至少8个字符，或者要求字母和数字等等，这简直令人沮丧。

如果您需要具有最大字段大小（例如，用于存储在数据库中），请尝试使其足够大，以便人们可以手动输入任何内容。实际上没有太大的密码字段，因为总是有可能使用自动生成的强密码，但64到128个字符肯定就足够了。

Answer 5

从根本上说，应该允许大多数unicode类字符。但是要跳过控制字符（例如0-31除了空格），字节顺序标记（0xfffe和oxfeff）。此外，您希望首先规范化表示以消除由不同表示引起的问题。您可能会发出警告但是对于似乎难以输入的字符，但用户会自行防范。

Answer 6

请记住：当您存储密码时，所有密码都应使用单向算法加密，例如sha1的md5。由于这些算法总是产生十六进制数，因此您无需担心SQL注入或类似的事情。

所以，只要你能为md5或sha1一个字符，就应该接受它。

Answer 7

如果您正在谈论防止SQL注入类型的攻击，那么确保您的代码能够执行预期的操作可能更好，而不是依赖于限制输入以使问题变得更容易。

对于非ascii字符，如果您的输入可以正确表示为二进制字符串（而不是 text ），我认为这不是一个更难的问题，然后将其传递给你的哈希函数或密钥生成器等。

Answer 8

为“让用户包含其界面允许他们输入的任何和所有字符”添加另一个投票。我甚至不会禁止制表符或控制字符。您的软件能够接受任意字节字符串并对其进行散列，因此接受任意字节字符串作为密码。否则会减少攻击者必须在蛮力或字典攻击中搜索的空间。

（当然，即使您确实允许所有内容，99％的用户仍会使用他们的宠物名称作为密码...）

Answer 9

最终，您可能需要在发送给您的用户的确认电子邮件中打印清除密码。

PS：也可以考虑编码电子邮件中的问题，如果它不是标准的ascii（例如日文字符），用户可能无法以正确的格式接收电子邮件或者根本无法在另一个系统上读取它由于没有安装字体。

所有这些都在“可打印的”ascii字符范围内。