对于 PHP，我想对密码使用 preg_replace() 过滤器，以便密码唯一可用的字符是 US ASCII 类型、减控制码和 NULL。
实现我可以插入 preg_replace() 的 RegEx 是什么？
编辑：
我被建议编辑这个问题，因为我现在“明白了”并且不会使用这种非常不受欢迎的技术，并且将允许任何可键入的字符，即使是我键盘上可能没有的字符，只要它们不是控制代码。
问问题
2611 次
6 回答
19
正如其他人所说，不要限制密码中允许的字符集。仅仅因为您的键盘上没有 ä、å 或 ö，就没有理由阻止我们这些拥有它们（或知道如何键入它们）的人使用这些字母。无论如何，您都会将密码存储为加密哈希（或至少作为加密字符串），不是吗？如果是这样，那么您的数据库是否可以成功/安全地将实际字符存储在密码中并不重要，只有加密算法输出的字符才重要。（如果不是，那么以明文形式存储密码比密码可能包含或不包含的字符要大得多- 不要那样做！）
您显然有意通过默默地删除您不喜欢的字符而不是告诉用户“再试一次，这次只使用这些字符：a、e、i、o、u”来强制执行字符集限制。使您提出的方法非常糟糕，因为这意味着如果我尝试使用密码fäîry（不是非常安全，但应该能够抵御轻量级字典攻击），我不知道的实际密码将是fry（如果您的密码是一个三个字母的单词，直接从字典里拿出来，在常用的情况下，你甚至不用费心）。哎哟!
于 2009-06-29T10:56:28.127 回答
10
就个人而言，当网站或服务试图强迫我使用遵循某种（通常是彻头彻尾的愚蠢）限制的密码时，我总是感到非常不安。
不是密码的全部意义在于它们不容易被猜到吗？为什么您希望它们比您的用户希望它们更简单？我无法想象需要对密码使用“仅 ASCII”的技术限制。
让您的用户使用他们喜欢的任何密码，对其进行哈希处理并将其存储为 Base64 字符串。这些只是ASCII。
于 2009-06-28T13:33:56.343 回答
4
干得好：
^[ -~]+$
假设您不想要空密码；否则是：
^[ -~]*$
允许空的。
我不确定你为什么要问preg_replace- 我会警惕操纵人们输入的密码。最好强制执行您只接受可打印 ASCII 的规则，并告诉用户他们是否违反了该规则（或者，正如其他人所说，没有任何规则，但我认为您有理由这样做）。
如果您正在考虑悄悄删除不匹配的字符，并且有人提供密码 Úéåæ，那么您将在他们不知情的情况下为他们存储一个空密码。
于 2009-06-28T13:27:39.973 回答
1
请不要过滤您的用户密码。这在很大程度上否定了这一点。我在这里写了更多关于这个：http ://www.evanfosmark.com/2009/06/why-do-so-many-websites-fail-with-password-restrictions/
于 2009-06-29T09:32:01.950 回答
0
我不同意没有理由拒绝非 ascii 字符，尽管由您决定利弊是否大于利弊。
如果您允许非 ascii 字符，那么您实际上是在致力于正确地国际化您的 Web 应用程序的那部分。对于许多应用程序来说，国际化是事后才想到的。对于 Web 应用程序，这是一件非常重要的事情。
如果您在字符和字节之间切换时没有明确控制字符编码，那么您基本上依赖于您的部署的默认值。如果您的配置发生变化（例如，从 Windows 迁移到 Linux，或切换到另一个 Web 服务器），那么您的默认设置很可能会从您下面更改，然后非 ascii 字符将序列化为不同的字节序列。因此，突然之间，在密码中使用它们的人的哈希值与数据库中的哈希值不匹配，他们将被锁定在他们的帐户之外。
当然，我同意仅过滤掉这些字符是完全不可接受的。您必须接受或拒绝密码。
于 2009-07-02T20:43:34.060 回答
0
/[\p{Cc}]/ 获取控制字符（我认为这涵盖了 0-31）
我同意里奇的观点。使用 preg_match 而不是 preg_replace。
于 2009-06-28T13:50:22.613 回答