应该允许用户输入开头或结尾有空格的密码吗？ [关闭]答案

【问题标题】：Should users be allowed to entered a password with a space at the beginning or end? [closed]应该允许用户输入开头或结尾有空格的密码吗？ [关闭]
【发布时间】：2010-10-12 13:01:00
【问题描述】：

用户是否应该能够输入诸如“12345”或“12345”之类的密码——开头或结尾的空格？或者您是否会修剪密码以删除前导或尾随空格，因为它可能只是输入错误。

【问题讨论】：

Google 和 Microsoft 似乎正在修剪密码，所以这个想法似乎并不牵强。
晚了10年...但是这个答案提供了很好的权衡...ux.stackexchange.com/a/8020/67374（基本上，不要修剪密码，但是在登录时，如果密码失败，请静默重试带有修剪后的密码）。双赢局面。
永远不要更改输入的密码！

标签： passwords

【解决方案1】：

是的，他们应该这样做。

当人们决定我的密码应该如何表现时，我感到非常恼火，尤其是当它是无意义的时候。我想要超过 8 个字符。
您应该对密码进行哈希处理，因此末尾的最大字符长度和空格无关紧要。

不，你不应该修剪它。

您需要用户输入两次密码（在创建密码时）以消除输入错误。因此，空格无关紧要。

【讨论】：

我认为是时候停止为少数太愚蠢而不会不小心在密码前加空格的少数人担心了，两次，然后把它写下来（不好），然后忘记它。他们赢得了它，imo。
我不同意这一点。在输入登录密码时，有人可能会复制并粘贴它，这会在此处或那里添加额外的空格。如果你不在你的登录处理代码中修改这个，他们将无法登录，即使他们的密码是完全相同的。特别是如果您的听众是非技术性的。所以不，不应该允许空格。
@Click 这是一个很好的观点。我认为这是那些棘手的情况之一。如果我有无限的资源，我会检测粘贴事件与类型事件，并显示一条消息，指出粘贴末尾有一个空格。
@TeeJaay 这是一个可怕的想法。很多人会生成类似 15 个字符的密码 - 你不能指望人们慢慢输入这些密码。
@Tom 你是对的，仔细想想，我必须同意我不知道那天我喝了什么。

【解决方案2】：

让我告诉你一个故事。

我需要在电子商务网站上创建一个帐户，所以我运行我的随机密码生成器来制作一个 8 个字符的大写/小写/数字/标点符号密码，将其粘贴两次以确认它，完成了我所有个人的注册信息，并将随机密码保存在本地 PGP 加密文件中以备后用。

后来我尝试登录，但再次粘贴密码不起作用。经过一番测试后，我惊恐地发现该网站已经从原始密码中删除了所有标点符号，这是一次错误的清理尝试，将我的密码减少到三个容易暴力破解的字母。

不要修剪或清理用户的密码。

【讨论】：

好故事，不太确定它是否完全相关，但有利于人们了解/观看。
我认为这很相关——他说的是更改用户的密码，以便接受的密码尝试与用户可能想要的不同（并且可能更容易）。
似乎与我直接相关。
好的，“完全相关”的意思是它不是关于密码，而是关于一般的密码验证，这就是问题最终的意义所在。仍然 +1 以获得很好的答案。
我同意 100%。除了领先和落后 WS 的情况，这只是等待发生的意外...... :)

【解决方案3】：

永远不要仅仅为了解决“输入错误”而“清理”密码。这会使用户感到困惑，并且在某些情况下使他们无法登录。事实上，永远不要在用户背后更改密码...始终警告他们密码无效并让他们尝试新密码。

我最近遇到的一个很好的例子是 3Com 交换机。 Web 界面允许我更改管理员密码，但没有警告我密码限制为八个字符。我输入了一个超过八个字符的密码。当我在更改后尝试登录时，它只是拒绝了我的密码。但是，如果我只使用前八个字符，我就可以登录（我的尝试和错误，不好玩）。

现在的密码看起来不像以前那样了。例如，我的密码通常是这样的：

Man, this program is really ticking me off!

【讨论】：

这让我想起了我现在多次使用 Windows 密码的糟糕经历。我将构建一台机器，配置管理员密码，然后将其加入域。域强加了我的密码不匹配的密码复杂性规则。现在我无法登录到管理员帐户。呸。
回到黑暗时代，我的 AIM 帐户是 AOL 帐户时遇到了这个问题。通过 AOL，我可以使用我的完整密码，但显然它每次都只是在幕后截断为 8 个字符，因为当我开始使用独立 AIM 时，我只能尝试 8 个字符才能登录。

【解决方案4】：

无论如何，您都应该使用确认字段来验证密码。如果他们打错了两次 - 那么你希望有一个忘记密码或重置功能。

空格无关紧要，因为您不应该将其存储为纯文本。

【讨论】：

【解决方案5】：

您做出此类决定的那一刻，就是您开始走上微观管理道路的那一刻（在这种情况下，是指您的用户）。

包含空格的密码会破坏您的系统吗？还是存在安全风险？然后别担心。让您的用户处理他们自己的错误，即使这意味着他们必须感到沮丧。他们的错字永远不会是您的问题。

【讨论】：

您应该微观管理和衡量您的用户体验。转动转盘，拉动控制杆，看看有什么棒子！ “让你的用户处理他们自己的错误，即使这意味着他们必须感到沮丧”这种态度缺乏同理心，不是我推荐的路径。
@jms：我猜你喜欢在 Office 中使用回形针吗？

【解决方案6】：

空格是一个普通的密码字符，你不应该删除它。

由于您可能在将密码存储到数据库之前对其进行哈希处理，因此空格将被视为任何其他字符。

【讨论】：

【解决方案7】：

我不止一次参加过一个会议，有人在电脑显示屏已经在大屏幕上显示后登录他们的帐户进行演示，没有正确地将焦点更改为密码字段，因此他们的密码向全场观众揭晓。

任何可能需要在其他人面前输入凭据的人都应该考虑在密码中保留一个或三个空格，以防万一。在构建身份验证系统时，您应该永远修剪这些空间。

【讨论】：

嗯...如果你知道一切，除了我添加了多少空格，你认为使用试错法猜出我的密码需要多长时间到最后。包括我输入它需要多长时间......希望你故事中的那个人在演示后更改了他的密码！
不知道：我不认识主持人。从黑客的角度来看，如果我不知道他们附加了空格，我可能会认为它已经改变了。从演示者的角度来看，我希望它能让我有足够的时间在更改演示文稿之前完成演示文稿，即使黑客坐在有 wifi 的观众席上。

【解决方案8】：

我不在乎。只要您在设置密码时对密码执行的任何操作，在稍后输入时也会对其执行。修剪、截断、更改大小写、加盐、散列等等 - 只需始终如一地执行即可。

大概您并没有存储实际密码，所以...

【讨论】：

好点...检查代码...
字。用户总是在剪切和粘贴文本，而最后的空间每次都会得到它们。修剪它，保持一致，不要打扰我。
除非您可能会在不警告用户的情况下降低密码的复杂性。如今，人们倾向于考虑这样的事情。
@Boden：如果您关心强密码（并且您应该），那么执行规则，指定足够的字符和长度来制作强密码。如果你认为它会使东西更有用，那么修剪。只要您保持一致，它们就不会相互排斥。
NO!!! 不要不要更改用户的密码entry - 按原样使用 entry。无论您在将其表示形式存储到数据库之前做什么后处理 - 例如，作为一个很好的示例散列 - 始终如一地执行 that - 但要使用 entry 在用户输入时。你做的任何其他事情只会导致麻烦 - 重新阅读上面由 @Josh Kelly 和 Boden 讲述的故事，如果你仍然不明白，请重新阅读直到你这样做！

【解决方案9】：

如前所述，密码包含它很好，但是我要补充一点，在生成新的随机密码时（例如，对于一个合理的重置丢失密码系统），您应该避免生成包含此类棘手字符的密码。

如果密码足够长且随机，那么这将弥补一些棘手字符的限制，从而使最终用户的生活变得更加轻松......

【讨论】：

我通常会尽可能避免生成密码，而是让用户在忘记现有密码时单击链接输入密码。管理员创建帐户时会自动生成一个密码。
@DarrylHein 发送链接比发送密码更好，用户必须在登录后立即更改才能使用它？如果一个不良行为者截获了带有链接的电子邮件，它将产生与他们获得一次性密码完全相同的效果。我看不出增加系统复杂性以处理密码重置链接如何增加安全性 - 如果有的话，它降低整体系统安全性，因为有更多地方可以破坏。
@FKEinternet 我同意这不是 100% 比发送密码好，但你可以做两件事来提供帮助：（1）只允许链接使用一次，（2）放一个时间限制链接的工作时间。这至少可以防止有人以后在他们的电子邮件中找到用户的密码。如果使用他们的电子邮件进行验证并且有人可以访问他们的电子邮件帐户，我认为无论如何你都会被圈套。我看到许多链接和临时密码从未更改过。

【解决方案10】：

我投票支持：否，他们不应该：

不允许用户在密码的开头和结尾使用空格有一个很大的好处，那就是它消除了用户复制和粘贴密码时经常出现的问题（例如从一封电子邮件），其中包含不属于密码的空格。

然后用户感到沮丧，认为系统已损坏并联系支持。开发人员被迅速拉入项目以检查“错误”的登录过程，结果却花了一天时间拔掉他/她的头发，直到他/她意识到问题。

我认为在创建密码时执行此策略解决的问题多于它造成的问题。

【讨论】：

您应该在这种情况下使用双输入，因为尾随或前导空格仍然有效，而对于出现两次错误的边缘情况，您可以重置密码。在第一次输入后永远不会看到密码，因此使用什么字符几乎无关紧要。
我之前多次看到的烦恼是用户将密码存储在文本文件或电子邮件或其他任何东西中。然后他们将其复制并粘贴到登录（不用于注册）。所以，遗憾的是双输入不适用于这种情况。也许这是一个边缘案例，我一直很不走运？！
不，我不认为你不走运，我认为你正在与普通用户打交道（没有人知道任何事情通过电子邮件发送密码）这很好登录，但是当创建一个密码，你应该防止复制和粘贴。
@BrillPappin - 我想不出双输入可以解决问题的情况。他们要么从某个地方复制粘贴密码，然后重复两次，要么手动输入密码，几乎不会犯这样的错误。另一方面，我认为密码的强度不应依赖于前导空格/制表符。密码生成器永远不会创建这样的密码，最坏的情况是您丢失了密码的 1 个字符的强度（如果在修剪后检查最小长度，我看不出任何问题）。
@Lee - 您仍然需要允许空格，因为它们是有效字符。关键是不要强迫用户使用较弱的密码，或者在他们不知道的情况下修改密码。给他们一个错误要求他们删除前导或尾随空格比修剪它们要好得多。

【解决方案11】：

由于将密码存储为文本是不好的，因此无需 trim() 密码，因为它会立即被散列。

... 在类似的注释中，我是否正确地认为密码不需要进行正则表达式验证以进行 sql 注入，因为它们将被散列并且不会作为纯文本插入数据库中？

【讨论】：

我认为你在后面是正确的，除非你在 SQL 中直接使用 MD5() 或类似的东西。
根本不应该对输入进行正则表达式验证。只需转义所有有问题的字母。
@Darryl，感谢 Jeff 的博客，我将使用 SHA256。