为什么某些站点会阻止密码中的空格？

16

在较新的网站上似乎不太常见，但是我需要使用多个帐户（例如，用于支付帐单等）的网站阻止我创建带有空格的密码。这只会使事情更加难以记住，而且我知道密码对数据库的空间或编程没有限制，否则会进行加密或（禁止使用天堂符号）。那么，为什么在注册站点时通常会歧视空格键呢？

security login privacy

— 伊恩·亨特
source

假设SSO需要非空白密码（虽然不确定），则可能某些网站使用“单一登录”！

— NoChance 2011年

1

真正让我感到恐惧的是，当网站明确禁止使用单引号时。除了启用以外，您还有什么可能的原因"insert into USERS (..., password) values (..., '" + $POST['password'] + "');" ：-S

— Christian Klauser

应该去安全，而不是程序员。虽然这可能已经存在。

— Dan McGrath

20

网站上的密码有很多愚蠢之处。

有些纯粹出于技术原因（有效与否，这是另一个问题，但几乎所有的原因都不存在）：

您的密码必须为四个字符，并且只能包含数字。

（通过将密码限制为0001 .. 9999范围，您可以简单地将它们以数字，纯文本形式存储在数据库中）

一些错误的想法解释了其他一些问题，它们将使密码更加安全：

您的密码必须以大写字母开头，并以数字结尾。

（通过这样做，开发人员或管理人员假设这实际上将迫使用户选择安全密码，而规则为“您的密码必须包含至少6个字符，并且至少包含一个大写字母，小写字母和一个数字”将魔术般地失败了）

最后，其他原因是通过以下事实来解释的：密码以纯文本形式存储，并且在如何存储，处理或检索密码方面存在一些歧义，并且没有时间对它们进行单元测试。

您的密码包含无效字符é。

要么，

您的密码y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!d包含一些无效字符。仅使用拉丁字母和数字中的字符。

要么，

您的密码不能包含空格字符。

在这三种情况下，开发人员只是确保可以正确存储这样的密码。

在第一种情况下，如果在发送时é会转换成%C3%A9什么？还是如果数据库存储é不正确怎么办？
在第二种情况下，如果PHP（为什么要使用PHP？）不能处理unicode，并且在收到这样的密码时发生了什么可怕的事情呢？如果<性格引起麻烦怎么办？如果将&字符解释为URL中的分隔符（假设由于某种原因，密码是通过GET而不是POST发送的）怎么办？如果'数据库解释了该怎么办，因为猜测，我们不知道什么是SQL注入以及如何避免它？或'转化成\'什么？
在第三种情况下，如果在某些情况下（而不是在其他情况下）PHP（再次？）修剪空白怎么办？如果管理员（他们出人意料地以纯文本方式访问用户密码）丢失了，因为他们只看到一个空格，而用户却设置了三个连续的空格，怎么办？

在这三种情况下，这些歧义都可以通过测试（尤其是单元测试）轻松解决。但是在大量项目中，根本没有测试，也没有时间进行测试（但以后仍有大量时间进行调试）。

这意味着开发人员是否要考虑允许空格，unicode字符或ASCII 48..57∪65..90∪97..122之外的任何字符（数字，小写字母，大写字母）可能造成的后果，最简单的方法，当测试是不可能的，是只禁止他们。

我认为，这是禁止使用空格的唯一原因。Yannis Rizos给出了另一个与UX有关的原因。尽管从理论上讲是一个合理的理由，但实际上它根本不起作用：由真正关心UX的人创建的网站无法修复愚蠢的密码规则。相反，实际上禁止使用空格的网站大部分是由从未听说过UX的人完成的。尤其如此，因为从UX的角度来看，禁止任何字符确实很烦人，因为与密码相关的任何限制（包括有用的限制）都是最小字符数。

— 阿森尼·莫尔琴科（Arseni Mourzenko）
source

更不用说消除空格时，您将消除一堆易于记忆的长密码（并且事实证明，长密码比复杂度更高，更能防止破解），并鼓励用户采用乱七八糟的密码，而这些密码远不如长密码系列令人难忘。的空间。

— 冒犯君主

1

我确实同意我所读的大部分内容，但是我很难理解“不可能进行测试时最简单的方法”这一说法。无法测试？？？任何同意发生该项目的人：愚蠢可以有效地最大化……是的，我知道它会发生：-|

— 托马斯

@Thomas：这是一般的理论和知识与实践之间的区别，它具有普遍的无知和时间限制，在这里许多人不想浪费时间进行测试，而忽略了他们将花费至少两次以后的调试。

— 阿森尼·穆尔琴科（Arseni Mourzenko）2011年

如果对于诸如自动电话访问之类的东西可能需要相同的密码，则要求用户定义仅由数字组成的密码可能是合理的，但是这种密码不应成为基于计算机的访问的主要身份验证凭证。

— 超级猫

3

答案是历史

我们似乎忘记了很多这样的基础来自于，当存储没有有效的分类（在磁盘或内存），当我们的管理所有这些事物的能力是略小于它现在是一个时间同样自动系统的能力尝试破解同样也少了一些。

基于我们现在知道的知识和我们现在可以做的事情，有很多关于密码的怨言，但简单的事实是，我们经常将遗留思维和遗留系统结合在一起。

现在新系统应该有限制吗？我希望不要-现在更少的理由

— 墨菲
source

您是说对密码中的空格进行了技术限制吗？存储在其中究竟发挥了什么作用？

— 伊恩·亨特

1

我建议技术限制和不太复杂的外部约束（可能使用“修剪”）意味着人们对什么是适当的和允许的有不同的看法。您可能对密码设置了限制，以确保密码易于记忆，因为重置密码比较困难。您可能不对它们进行加密，因为仅是（当时）到达一个您可以阅读它们的地方相对困难（并且在任何情况下都无法从外部访问系统）。不同的时间，完全不同的思维过程留下了遗产

— Murph

2

恕我直言，使用现代哈希和/或加盐法存储密码以不允许在密码中留有空格的任何网站/应用程序都是愚蠢的。但是，某些遗留系统（在某处了解到此信息）仍然以纯文本形式传递密码-因此不允许在此处留空格可能有意义。另外，某些应用程序可能“剥离”它们接收到的所有字符串输入。因此，以空格开头或结尾的密码不是很好（当然，这是人为设计的，但是您可以想象几乎任何人提出自己的网站都不会发生这种情况）。允许在密码中留空格没有什么“坏”之处-正如您所指出的那样，DB不会禁止使用散列或纯文本版本。

实际上，我的大多数Windows朋友都不知道他们可以在密码中使用空格-因此，按照蒂姆·梅多拉（Tim Medora）的回答，网站所有者可能不想冒险使用lamahs（请原谅），或者其中一些人拥有误解和/或不知道空间可以提供的优势。

— 亚提传奇
source

1

我更喜欢从密码中删除前导/后缀空格，因为它们往往会引起问题，但这并不是拒绝它们的理由-它们只会在设置和测试上都被剥夺，没有问题。

— 洛伦·佩希特尔

“问题”到底是什么？我一直在强调应该允许空格的答案。“他们将在设置和测试上都被剥夺”-那么有什么意义呢？然后“ 1 4m 1337”和“ 1 4am 1337”都散列为相同的值（实际上，理论上存在无限数量的可能性）。

— yati sagade 2011年

What's the point then?另一个要点是，密码没有用户期望的熵。而且某些系统默认情况下会修剪GET / POST变量，对此行为的（不太可能）更改将导致更严重的问题。

— yannis 2011年

@Yati传奇：我不是在谈论剥离内部空间。我说的是前导空格和尾随空格-人们没有意识到空格在那里，这会导致登录失败。同样，如果您看到一个全部大写的密码都将其翻转为小写，则可能是有人没有意识到大写锁定已打开。

— 洛伦·佩希特

-1

出于同样的原因，很多网站都不允许在名称中使用连字符，撇号或非ASCII字母，即使在美国这是非常常见的做法，并且除简单允许之外，禁止这些字符还需要做更多的工作他们。

出于同样的原因，许多网站的单词过滤器也不允许您使用“自欺欺人”，“延缓”甚至“蓄积”之类的词（尽管许多常见的种族诽谤完全没问题），因此这样做也是出于同样的原因。

这是因为许多开发人员显然完全缺乏常识，或者在考虑可能的用户输入和方案时至少具有非常有限的想象力。他们中的一小部分可能正在处理错误信息（排除非字母数字字符在某种程度上是一种标准做法，或者散列算法或存储方法无法处理空格或特殊字符）。其他人可能只是懒惰-他们担心字符集问题，因此他们只是将输入限制在最小的字符空间内。然后可能是由于缺乏对真实威胁的理解而由于偏执狂而过度投入的输入验证/卫生。

— 莱斯特·马杰斯特（Lèsemajesté）
source

除了强制执行特定字符编码外，您还需要采用白名单的原因是什么？我基于此观点，限制任意字符在削弱用户选择的密码时没有任何好处。我给出的所有示例都是开发人员没有充分考虑设计选择的症状。

— 2011年