是我从某些网站上看到的消息，
包括1个。
为什么？
（这个问题非常相似为什么为什么不允许在密码中使用特殊字符？，但是答案似乎不适用于空格字符。）
某些系统显然会在对密码进行哈希处理之前去除所有空格。
（Google如何不关心应用程序专用密码中的“空格”？）
为什么不简单地对用户键入的内容，空格和所有内容进行哈希运算？
#1 楼
我无法将其解释为除了传统的疯狂之外的任何事情，或者是无意中将用户名限制懒惰地复制到密码限制。如果您对密码进行哈希处理，则任何可打印或其他方式的数据块都可以接受。唯一的限制应该是最小的复杂度和“合理的”最大长度，以便有人每次登录时都不会占用1MB的带宽（以及由于使用慢速算法而对输入进行哈希处理的相应CPU时间，对吗？）。
评论
使用密钥派生方法时，即使第一轮花费的时间稍长一点，哈希时间也不重要吗？
– Lekensteyn
13年3月15日在16:25
好吧，我不会说这无关紧要，但是您是对的，无论输入什么，第一轮之后的所有回合的时间复杂度都是相同的。
– Jeff Ferland♦
13年3月15日在17:33
我会检查相关的客户端环境中的字段输入限制。例如，在线服务需要允许从Web浏览器登录，因此输入限制应与浏览器表单字段限制（如果有）相关。另外，拒绝换行符可能会防止客户端平台不一致问题（\ r \ n与\ n）。
–罗伊·廷克（Roy Tinker）
2013年3月15日21:52
不要忘记强迫浏览器一直实际发送UTF-8，否则您将遇到讨厌的错误。
–Reactormonk
13年3月16日在12:15
@Laurent：确保用户能够做到是用户的工作。但是坦率地说，如果您接受“共享密码”的想法，您在这里做什么？
–于尔根·艾哈德（JürgenA. Erhard）
13年4月24日在15:07
#2 楼
前导和尾随空格可能会给那些粘贴和粘贴不全的人带来麻烦。否则，请与其他帖子达成一致，没有充分的理由。尽管如此，我们还要屏蔽哪些其他字符？ Tab，cr，lf，backspace，哔哔☻☺♪☻☺。 ？
评论
ewanm89-如果在幕后剥去空白而不是在前面删除密码，则会遇到故意使用空白的情况。当然，这种情况很少发生。
– AndrewStevens
13 Mar 16 '13 at 0:16
@AndrewStevens但是，即使是有意添加的，用户也可能不会注意到空白在幕后被剥离（只要每次输入时都会被剥离，而不仅仅是在创建密码时被剥离）。
– Peter Olson
13年3月16日在16:53
@PeterOlson：我想我的观点不好（请问我的错-对不起= P）我想说的是，我认为用户依靠尾随空白来输入密码是不好的很长，但是没有告知何时删除空格。这意味着用户密码的安全性可能要差得多，但是用户不知道。
–凯文
13年3月16日在20:58
@Kevin，我认为这更多是一个UX问题，如果您在创建时注意到密码中包含尾随空格，则警告用户不建议这样做。不要阻止他们这样做，但要告诉他们密码不那么安全。
– Ziv
13年3月18日在21:16
至少要删除尾部空格的另一个原因：在电话/平板电脑软键盘上，很容易在用户名和/或密码之后获得额外的空格。
–德罗伯特
13年3月19日在20:24
#3 楼
简单的答案是，这是错误的密码策略。我认为没有特别好的理由禁止使用空格字符。这可能只是一个善意但错误的人设定的一些任意要求。
#4 楼
我不能想到任何可靠的安全原因，除了它会阻止人们使用实际句子作为密码之外，如果他们具有实际含义，那将是非常不安全的。严格来说，如果密码中的空格保持良好的熵，就不会有任何不安全感，因此人们只能“创意”，这是我能看到的唯一真实内容。也可能存在可用性问题如果很难看到密码，则很难从视觉上确保空格正确键入。 （是一个空格还是4，如果出现一个* s，就很容易计数了。）
评论
密码的句子并不是那么不安全，比起128个字符（ASCII）的5个字符，还有更多可能的方式将大约250,000个单词的字典中的5个单词串在一起。即使我们只选择对随机的单个字符具有含义的单词组合，也会碰到更多的熵，问题是某些短语可能比其他短语更常见，这也是字符串用作密码的问题。最后，拒绝空格不会停止使用句子，只是不要在单词之间放置空格。
– ewanm89
2013年3月15日19:18
是的，但这与使用密码的人没有什么区别，因为那里有密码...相同的问题同样适用，句子更容易记住，并且含义可能千差万别，在两种情况下使用最常见的情况总是很糟糕，因为这将是攻击者首先尝试的方法。
– ewanm89
13年3月15日在21:20
@ ewanm89实际上，它与使用“密码”有很大不同。实际上，“这是我的密码”比“密码”安全得多。另外，如果需要数字和特殊字符，您可能会以“ 1his is my p @ ssword”结尾，这至少比“ p @ ssw0rd”更安全。最后，这可能很有启发性：xkcd.com/936
–帕特里克M
13年3月16日在16:05
@PatrickM取决于攻击者是否知道您使用的是短语。如果攻击者拥有最常用短语的短语字典，则与最常用密码的字典相同。
– ewanm89
13年3月16日在23:53
@AJHenderson是的，它可能比“选择正确”的英语单词还差，但是如果您需要密码策略，则假定大多数用户不会“选择正确”他们的密码。基本上，我的主张是，错误选择的句子几乎总是比同样错误选择的密码更好。例如，人们经常选择他们面前的密码。因此，我可能会选择“马”或“白马”。 （一本随机出现在我面前的书）现在，我承认该短语是一个错误的密码，但该短语通常比同等错误选择的单词更好。
–帕特里克M
13年3月17日，1：11
#5 楼
这是一个非常方便的政策，从客户支持的角度来看，我认为这应该在任何地方实现。您可以这样写密码：“ abc def ghi”并复制它
剥去所有空格比告诉所有人要容易得多：
“确保您不是t复制并粘贴任何空白字符”
“手动输入密码，请勿复制并粘贴”
通常可以回答以下问题：
“即使我从您发送给我的电子邮件中复制了密码，我的密码也无法正常工作”。
评论
或者可以简单地写为“ abc def ghi” ...
–凯文·费尔柴尔德（Kevin Fairchild）
2014年8月6日下午0:41
这有两个大缺陷。首先，如果空格是一个问题，那么您可以在散列密码和用户登录之前将它们简单地隐藏在幕后。第二，如果您要向他人发送密码，那么您遇到的问题比空格大。同样，在散列之前和登录时代表用户删除空间也可以解决复制粘贴问题。
– wgp
16年1月16日在20:50
如果您必须向客户提供初始密码，请生成一个没有空格的密码，以避免出现您提到的问题。但是客户应该能够将此初始密码更改为另一个包含空格的密码。
–丹尼尔（DanielFrużyński）
18年7月6日在10:02
#6 楼
它仅关于程序语义。大多数事物处理空格字符''或'“的方式都不同于其他符号，例如'a'或'dds'。空格字符会混入其他奇怪的字符中，例如换行-'\ n '或空白字符-''
它也不是唯一的，因为某些计算机环境上的某些特殊字符没有表示形式，而是被解析为空白字符''
在某些计算机环境中，我们将文件从MAc来回传递给Windows，再传递给Linux，有时我们会以（''==''）产生FALSE结果（双等号只是表示比较运算符）。这是错误的，因为由于团队中计算机文化的差异，我们无法看到该空间中存在的隐藏符号。
我不确定当严格讲话时是否会出现此问题密码，但是在特殊区域中没有空格（例如密码，函数名和文件名）绝对是更好的选择。解析文件名中的空格是另一回事，有些程序在空格中添加％以删除空格，因此您将其命名为％name
评论
您提到的所有内容严格来说都是编码问题，不会对设计正确的密码哈希系统产生影响。
–user10211
13年3月16日在1:16
哦，那么，只需在通用知识库中添加更多阅读材料即可。
–约旦
13年3月18日在21:31
乔丹的答案至少是相关的。诸如他提到的空格之类的问题可能有助于构造“密码中没有空格” /“空格可能是有问题的”范例。即使空格不应该影响正确设计的密码哈希系统，但它们导致其他代码中的错误的趋势可能使某些人害怕禁止在其站点上使用密码。
–user22208
13年3月19日在2:25
#7 楼
在大多数键盘上，空格键的声音与任何其他键的声音略有不同。请考虑有人听到别人输入密码的情况。
如果该人能够确定密码由例如3个字符+空格+ 4个字符组成，那么在某些情况下这可能是非常有用的提示。
评论
在许多情况下，相同的论点也可能会针对许多其他种类的非字母数字字符（尤其是重音符号）以及混合大小写的使用（由于按键听起来与发行版不同，因此新闻发布与发行版不同从新闻稿中）。
–超级猫
14年2月2日，19：56
#8 楼
我可以想到几个应该排除空格的原因；这些原因与安全性无关，但与可用性无关：如果您发送的密码中包含空格，接收者如何知道它是空格还是制表符？是一两个空格吗？假设您必须手写（发生），如何显示此信息？同样，根据电子邮件客户端字体的不同，他们也可能不会注意到空格。
再次，在发送密码时，如果空格在开头或结尾，它将是很容易错过，必须用引号引起来。但是即使那样看起来也很奇怪，我可以轻松地想象用户不包括最后一个空格并且无法登录。
空白字符（换行符，制表符，空格）通常从字段的开头和结尾处修剪到避免人们复制和粘贴不正确的数据。显然，如果空格很大，那会引起问题。
总的来说，我认为没有空格可以避免各种问题并节省支持电话，所以这是一件好事。 >
编辑：
回答有关共享密码的不良做法的评论：
假设重要的业务文档被锁定在Bob的工作站上，而该工作站目前正在假期。在这种情况下该怎么办？等待鲍勃两周后返回并同时失去潜在业务吗？或者只是问他发送密码？肯定是不好的，但仍然比其他方法要好。
正如Linus Torvald所说（关于其他事情，但我喜欢这种精神）：“您应该处理现实，而不是您希望现实是什么” 。
评论
好吧，以明文形式发送密码不是一个好主意。
– jb。
13年3月16日在10:05
1）如上所述，以明文形式发送密码是一个坏主意。如果用户决定放一个空格然后尝试告诉别人他们的密码是什么，那就是他们的问题。如果这是为了恢复密码，请停止以纯文本格式存储您的密码，然后让用户重置其密码。 2）如果您没有正确地引用/转义用户的密码，那您就该等着您了。 3）如果始终对密码进行修剪，这有关系吗？毕竟，如果每个密码输入对话框都会修剪空格，那么用户看到的效果就不会太大。
–帕特里克M
13年3月16日在16:09
我认为您错过了重点，我是一名开发人员，我对密码进行哈希处理，我不通过电子邮件发送密码，我知道良好的做法，但这不是重点。有时密码是通过电子邮件，电话，写在纸上等方式发送的，这都是错误的，可以。但是，作为开发人员，通过在密码中留空格，会使其更加错误。对于无用的功能，这可能会浪费数小时的支持呼叫/电子邮件。
–劳伦特
13 Mar 17 '13 at 4:46
我不买如果有人选择在密码中使用空格，他们可以很容易地告诉别人注意该空格。根据您的逻辑，也不应使用大写字母。我会尽可能在密码中使用空格，并且已经通过电子邮件或口头多次分享了密码。我经常做的是说“密码是'My Password'-注意大写字母和单词之间的空格”。从来没有问题。
– wgp
16年1月16日在20:57
键入和手写都具有交流空格（甚至其他空格字符）的约定。并且根据此逻辑，也应避免使用大写字母I和小写字母l。对于这种非常狭窄的用例，可以选择不使用空格。您尚未提出系统地阻止其使用的理由。
– schroeder♦
20 Jan 28'在12:02
#9 楼
我相信大多数非程序员都（有意识或无意识地）感觉到空格字符与其他字符本质上的不同之处在于，空格字符仅用于将单词彼此分开。只是元数据而不是数据。由于没有与空格字符对应的声音，这种感觉得到了加强。大多数人会记住发音的密码（大声说出来的声音）而不是视觉的形式（写出来时的样子）。
因此，他们会不自觉地考虑“我的密码”，“ “我的密码”和“ MyPassword”之所以相同，是因为它们发音相同，而且即使一个空格也很容易看到（一个大写的“ P”）一个单词结束而下一个单词开始的地方。当然，如果您问他们这三个是否相同，您将把问题从无意识转向有意识，每个人都会回答“否”。但是只要没有人问这个问题...
因此允许在密码中留空格的问题是切实可行的：它可以帮助用户忘记密码，即帮助他们忘记是否存在空格（或两个）。密码中的三个或...）。
评论
本质上是不同的术语是（毫无疑问）空白。
–森林
19年7月3日在8:16
#10 楼
我将通过说我已经是一名系统管理员超过30年了，并且至少是一名作家来限定此评论。尽管在某些情况下可能允许在密码中使用空格圆圈，从某种意义上讲，这可能会更安全，因为您可以使用更大的字符集来加强密码...您正在通过这样做来寻求麻烦。一个空格不仅是一个字符，它还代表一个空的空格，就像一个零代表没有数字值一样。最终，这一天将会到来，您将“忘记”空间，并且想知道为什么您的root密码不再起作用，并且不得不从头开始重新加载服务器。从可用性的角度出发-我说要远离空间……这是“不成文的规则”之一，您可以给出一百个不遵守的理由，但坚持下去可以使您的生活变得更容易
。在三十年中，我只遇到一个使用密码中的
空间的人，试图弄清楚这真是太难了。其他人会不同意-那是他们的特权。我永远不会使用空格。
评论
空格字符不代表“空空格”。在某些Unicode表示形式之外，它只是一个八位的字符串，就像字母和数字一样。另外，零也不是缺少数值；这是一个有意义的占位符。如果您对此表示怀疑，请在您的一个可执行文件中用'00000001'x将所有'10000000'x二进制替换，然后看看会发生什么。 :)
–user46818
18年5月5日19:03
现在是2018年。我们有Unicode 10.0，其中包含1,114,112个枚举的字素。其中136,690人被分配和命名。每个符号的熵为17.061位（可以使用）。该行业已经过去了跟上技术发展的步伐，并停止了过去30年的反政策。禁止UTF-8代码点32可能是非常实际和技术上的原因，但现在不存在。要创建密码短语，用户应该可以自由使用任何Unicode代码点。生成加密，散列，拉伸（或旋转）的加密密钥。
– Mac
18年5月30日在14:53
评论
来自UX.SE上不同POV的一个相关问题是：我应该修整密码中的空格吗？。攻击者可以使用任何类似这样的明确限制来减少搜索空间。就像说它必须以数字开头或一定长度一样。
Microsoft Office 365帐户不允许使用空格和尖括号i.imgur.com/yxt96Jx.png。这是2017年，即XKCD普及了四个单词的密码六年之后，微软仍然无法处理空格。我认为它们只是将所有密码存储在某个地方的访问数据库内的大规模XML Blob中。
通常不应在密码，URL，文件名之类的任何地方使用空格。在每种情况下，它们都可能导致发生各种异常。
有趣的读物是，在NIST 800-63B中，应注意密码中应包含空格，请参阅pages.nist.gov/800-63-3/…猜猜不是每个人都在听他们大声笑