【问题标题】:preg_replace Filter for Passwordspreg_replace 密码过滤器
【发布时间】:2010-11-06 11:55:41
【问题描述】:

对于 PHP,我想对密码使用 preg_replace() 过滤器,以便密码唯一可用的字符是 US ASCII 类型,减去控制代码和 NULL。

什么是正则表达式来实现我可以插入 preg_replace() 的功能?

编辑:

我被建议编辑这个问题,因为我现在“明白了”并且不会使用这种非常不受欢迎的技术,并且将允许任何可键入的字符,即使是我键盘上可能没有的字符,只要它们不是控制代码。

【问题讨论】:

    标签: php regex filter passwords preg-replace


    【解决方案1】:

    我不同意没有理由拒绝非 ASCII 字符,尽管由您决定利弊是否大于利。

    如果您允许使用非 ascii 字符,那么您实际上是在致力于正确地国际化您的 Web 应用程序的该部分。对于许多应用程序来说,国际化是事后才想到的。对于 Web 应用程序来说,这是一件非常重要的事情。

    如果您在字符和字节之间切换时没有明确控制字符编码,那么您基本上依赖于您的部署的默认值。如果您的配置发生变化(例如,从 Windows 迁移到 Linux,或切换到另一个 Web 服务器),那么您的默认设置很有可能会从您下面更改,然后非 ascii 字符将序列化为不同的字节序列。因此,突然之间,在密码中使用它们的人的哈希值与数据库中的哈希值不匹配,他们将被锁定在他们的帐户之外。

    当然,我同意仅过滤掉这些字符是完全不可接受的;您必须接受或拒绝密码。

    【讨论】:

      【解决方案2】:

      正如其他人所说,不要限制密码中允许的字符集。仅仅因为 您的 键盘上没有 ä、å 或 ö 就没有理由阻止我们这些拥有它们(或知道如何键入它们)的人使用这些字母。无论如何,您都会将密码存储为加密哈希(或至少作为加密字符串),不是吗?如果是这样,那么您的数据库是否可以成功/安全地将实际字符存储在密码中并不重要,只有加密算法输出的字符才重要。 (如果不是,那么以明文形式存储密码是一个比密码可能包含或不包含的字符更大的问题 - 不要那样做!)

      您显然有意通过默默地删除您不喜欢的字符而不是告诉用户“再试一次,这次只使用这些字符:a、e、i、o、u”来强制执行字符集限制。使您提出的方法真正残酷,因为这意味着如果我尝试使用密码fäîry(不是非常安全,但应该能够抵御轻量级字典攻击),我不知道的实际密码将是@ 987654322@(如果您的密码是三个字母的单词,直接从字典中取出并常用,您甚至可以不打扰)。哎哟!

      【讨论】:

      • 嘿戴夫。我想感谢你让我明白这一点,并“我明白了”。问题是,在这个疯狂的系统中,我发表的这篇糟糕的帖子就像是我声誉的锚。我不能删除它,我不能提高我的声誉。我已向 stackoverflow.com 的开发人员投诉。人们真的会犯错误——我们不应该永远忍受这些错误。使用stackoverflow,除非他们解决此问题,否则您最终会遭受永恒的痛苦。
      • 乐于助人!而且,如果我正确理解了此处的代表系统,您的代表将不再受到问题的影响,因为它被标记为“社区 wiki”。
      • "或者至少作为加密字符串" -- 不
      • @Good Person:有一些个有效用例用于存储加密字符串而不是哈希,例如“密码保险箱”,因为应用程序的预期功能特别需要存储的密码可恢复。它们非常非常罕见,但它们确实存在。
      • @DaveSherohman:是的。我还希望编写此类工具的人是此类系统的专家:)
      【解决方案3】:

      请不要过滤您的用户密码。这在很大程度上否定了这一点。我在这里写了更多关于此的内容:http://www.evanfosmark.com/2009/06/why-do-so-many-websites-fail-with-password-restrictions/

      【讨论】:

        【解决方案4】:

        /[\p{Cc}]/ 获取控制字符(我认为这涵盖了0-31)

        我同意里奇的观点。使用 preg_match 而不是 preg_replace。

        【讨论】:

          【解决方案5】:

          给你:

          ^[ -~]+$
          

          假设您不想要空密码;否则是:

          ^[ -~]*$
          

          允许空的。

          我不知道你为什么要问preg_replace - 我会警惕操纵人们输入的密码。最好强制执行您只接受可打印 ASCII 的规则,并告诉用户他们是否违反了该规则(或者,正如其他人所说,没有任何规则,但我认为您有理由这样做)。

          如果您正在考虑悄悄删除不匹配的字符,并且有人提供了密码 Úéåæ,那么您将在他们不知情的情况下为他们存储一个空密码。

          【讨论】:

            【解决方案6】:

            就我个人而言,当一个网站或服务试图强迫我使用遵循某种(通常是彻头彻尾的愚蠢)限制的密码时,我总是感到非常不安。

            密码不是很容易被猜到的重点吗?为什么您希望它们比您的用户希望它们更简单?我无法想象需要对密码使用“仅 ASCII”的技术限制。

            让您的用户使用他们喜欢的任何密码,对其进行哈希处理并将其存储为 Base64 字符串。这些只是 ASCII。

            【讨论】:

            • 嗯...美国 ASCII 类型。他试图过滤的字符可能无效,尽管这确实让我问......为什么你甚至需要过滤用户可能无法输入的字符? HTML 表单应该是控制字符的自然缓冲区。
            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2019-08-30
            • 1970-01-01
            • 2012-09-30
            • 2011-11-15
            • 1970-01-01
            • 2016-04-30
            相关资源
            最近更新 更多