客户服务为何说在密码中使用符号不安全？

#1 楼

这些“安全措施”不是为了您的安全，而是为了他们的安全。

连字符，撇号，百分号，星号，斜杠，句号等符号对于攻击者执行“注入”很有用攻击，例如SQL注入，XPath注入，文件路径注入等。网站所有者希望通过阻止这些字符来阻止您攻击其服务器。

他们应该更多地专注于适当的攻击。数据处理，例如内部使用参数化SQL和特殊字符转义，但这是一种额外的措施，可以在他们的站点中隐藏编码错误的情况下充当权宜之计。


我无法确切回答“为什么”他们这样做。也许他们有一个安全审核员，他说“将白名单字符集用于用户输入，并阻止任何非字母数字符号”。也许他们购买的Web软件包带有该限制。他们的安全副总裁可能说：“添加一些可见的措施，使我们的客户有一种我们认真对待安全的印象。”谁知道为什么？

#2 楼

问题是，为什么他们说，当符号使密码更安全时，允许符号输入不安全？


不了解为什么制定某些规则并得出结论的客户服务，或者通过使用过去的这种借口并取得成果，或者在他们的脑海中积淀出来，这将使他们成为交易对象

您的解释是正确的，因为密码的复杂性通过添加符号以及字母，大小写和数字变得更加安全了。

我会把这写成一个未经培训的客户服务代理，只是想使工作变得更轻松，或者这个人知道政策存在缺陷，只想使这段谈话尽可能短。

#3 楼

因为他们可能使用输入卫生而不是参数化查询和输出卫生。

如果他们有参数化查询，这将不是问题。如果他们知道如何对输出进行清理，那么这将不是问题。

他们的代码很容易受到很多其他事情的影响，例如基于unicode的走私。对于许多“安全的开发人员”而言，输入卫生只是将输入中的撇号删除，这是一种非常糟糕的方法。

这不能防止基于unicode的走私，并且会干扰数据库中撇号的合法用途，例如人们的名字。想象一下试图在数据库中搜索某人的姓氏，但是您不能这样做，因为存在撇号。

正确的解决方案如下：输入验证（空>长度>格式>白名单）**> **参数化查询>输出卫生（以避免XSS），这可能不是以下。没有正当理由排除适当的数据。

#4 楼

同意您的分析，即允许使用符号可以提供更高的安全性，但总的来说并没有那么多。特别是与使用稍长的密码（假设密码是完全随机选择的符号）相比时。使用95个可打印的ascii字符中的任何一个：

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\]^_`{|} ~

（如果您将Tab或换行符等字符视为可打印，则还有更多）8个字符的密码具有95 ^ 8 〜6.6 x 10 ^ 15的可能性，而仅包含（区分大小写）字母和数字的8个字符的密码具有62 ^ 8〜2.2 x 10 ^ 14的强度，弱约30倍。

仅带数字+小写+大写字母的9个字符的密码比允许特殊字符的8个字符的密码强两倍。因此，除非对密码的长度有严格的限制（实际上，至少对于少于几百个字符的密码永远不需要），否则即使使用有限的字符集，也很容易转移到稍长的密码。 br />
最大的潜在安全隐患是，如果他们认为允许密码中的特殊字符会在其应用程序或数据库中引起问题。有合理的理由排除可能导致问题的不可打印的ASCII字符（例如ASCII控制字符NUL（\b），退格键（'）等），但是设计良好的应用程序应能够处理常规特殊字符，例如-或A3不受注入攻击的影响。应用程序应该能够处理这些类型的字符，例如出现在带有引号或连字符的名称中（例如，Conan O'Brien，Daniel Day-Lewis）。此外，由于不应将密码保存到数据库中或将密码退还给用户并立即将其散列，因此允许可打印的ASCII特殊字符无关紧要。

当然，对于非ASCII特殊字符（例如unicode），存在一些可用性方面的考虑，对于可用性方面的考虑，禁止这些字符或以标准方式对其进行规范化可能是一个好主意。散列函数通常需要一个字符串字符串，并且具有超出ASCII特殊字符的密码可以在字节级别以不同的方式进行编码（例如，UTF-8，UTF-7，UTF-16，ISO-8859-1）。此外，除了不同的编码（可以在应用程序级别上保持一致）之外，您还必须担心unicode中外观相同的字母具有不同的值。例如，以下字符Å是unicode 00C5，但此外观相同的字符是Åunicode 212B，而实际上是两个字符-ASCII字符unicode 030a的组合字符，在A上加了一个圆。

EDIT：我刚刚注意到您将£列为您的常用符号之一。不幸的是，这不是标准的ASCII符号。在ISO-Latin-1中，它是字节C2 A3。在UTF-8中，这是两个字节+AKM-。在UTF-7中，它是ASCII字符00 A3。在UTF-16中为'。这些不同的编码意味着，如果处理不正确，则散列函数可能会破坏此字符。当然，该应用程序应该能够正确处理编码，但是在某些设备子集上可能会失败。此外，该字符可能无法在外国键盘上使用。在密码上下文中完成）。

最后，还有一种独特的密码规则，那就是让用户拥有一个记住的密码，该密码在任何地方都可以重复使用，这是一种可怕的安全做法，这使用户更难。如果用户的“普通”密码不符合一个站点的唯一规则，则当他们的普通密码在某个随机的其他站点上遭到泄露（即以明文形式存储密码）时，该用户的帐户不会在该站点上被唯一口令破坏。规则。

#5 楼

有点久了，但是...

说，约翰的母亲得到了圣诞节的IPad，然后她决定使用它（而不是笔记本电脑）登录她的银行，但无法解决在iPad上“键入”符号。因此，她要求某人向她展示如何键入密码.....

现在考虑客户拥有不知道如何在手机或平板电脑上“键入”密码的客户的支持问题。许多要求重新设置密码的支持电话既是安全问题，也是成本问题。

#6 楼

某些符号可能无法在您与之交互的所有键盘布局上使用。这将阻止您登录。这将是可用性问题，而不是安全问题。

但是，如果您在陌生的键盘布局上可以使用该符号，这可能会成为一个轻微的安全问题。正在合作，但位置不熟悉。在这种情况下，您可能必须先找到正确的密钥，然后再将其输入密码字段。并且（尤其是在没有匹配的键帽的情况下），可以想象在一些编辑器中键入符号，直到出现要搜索的符号。当您停在那里时，一眼就能看到您的编辑器的人（在您键入或稍后输入该内容是因为您忘记关闭它）会知道您密码中包含的至少一个符号。

我有同意Eddie Studer的回答：即使存在牵强附会的安全隐患，告诉您此事的人也可能不知道该政策背后的真正原因。但是，这可能是我前面提到的可用性问题，例如用户无法登录。来自国外的网吧。只是为大多数其他答案表示的注射问题提供一种替代方法，即使这些仍然是很可能的原因。

评论

---

在我工作过的公司之一中，我们的用户设法以某种方式在他的密码中添加了制表符。然后我们收到了错误报告，指出他无法输入密码。因此，限制字符集并不一定是个坏主意。

–el.pescado
16年1月27日在18:23

---

@ el.pescado如何在标签中放入密码？它只是使您进入网站或浏览器的下一个字段，不是吗？还是输入\ t？如果是这样，那么密码之前就没有被清理过。

–iProgram
16年1月27日在22:37

---

如果您要从文本文档中复制粘贴密码，并在其中包含标签，则可以在密码字段中完全使用它。

–FélixSaparelli
16年1月28日在10:29

---

在某些情况下，您可以按CTRL-I输入制表符。但是，值得注意的是，这在IE中不会发生（我相信它会尝试在此处创建到当前页面的书签）。

–丹·亨德森（Dan Henderson）
16年1月31日在6:28

---

#7 楼

大多数人在不放慢速度并同时按下多个键的情况下不能键入符号，因此，如果您尝试键入可能被人看到的位置，则安全性会有所降低。

#8 楼

您的论点是：
1。具有符号的随机生成的密码要强于仅由字母和数字组成的相同长度的随机生成的密码
2。因此，允许密码中的符号使其更强壮。

只有当人们随机生成密码时，此方法才有效。
让我们将使用以下算法创建的密码进行比较：
1。创建最大长度的密码-1，其中包含数字和字母
2。在符号末尾粘贴一个符号

假设符号的数量少于字母和数字的数量，这将产生比仅包含字母和数字的随机密码要弱的密码，并提供错误的密码安全感（我将其设置为password $，而不是password！）。可以使用类似的参数来通过用符号等替换字母来生成密码。

因此，人们可能会决定禁止使用符号，以希望人们选择使用随机/更长的密码，而不是pa$$word 。当然，这会“破坏”想要使用带有字母+数字+符号的随机密码的用户。但是您希望这些用户会受过足够的教育，只需添加更多字符，就可以得到强度相同的密码（假设您没有限制长度）。

总而言之，仅因为在某些密码中包含符号会增强其强度，所以并不能因此而允许人们使用符号会增加普通密码的强度。

#9 楼

除了他们自己的安全性之外，假设您必须记住包含大写和小写字母，数字和特殊字符的密码，大多数寻求它们的人会将密码写在纸上，并且可能与他们的登录信息一起考虑了。高安全风险
如果您使用更简单的密码就可以记住，那么从您那里泄漏的可能性就大大降低了
当然，这样一来，它们会阻止您使用带有密码管理器的复杂密码的能力，因此解决方案比一张纸，但是我仍然认为它比简单地记住您的密码或密码不太安全
，但是如果没有内部人员的话，要告诉他们是否有合理的理由或者只是他们的系统或管理存在缺陷

#10 楼

XML / Json假设：

密码可能已发送到Web服务（希望通过安全通道），他们发现特殊字符导致无效的XML或Json。他们没有转义实体，而是限制了所有符号。

一个安全问题是，如果您能够在Json中使用转义字符“ XML和\”，并且XML / Json是由String串联构建的，而没有CDATA或转义，您可能会以引号结尾即使您在String中检查了单引号和双引号也是如此。

当然，解决方案是避免使用外部参数构建查询时避免字符串连接。

P.S：密码也可以用于LDAP，从而可以进行LDAP注入

#11 楼

我避免使用密码中的符号，因为它们可能很难键入，尤其是在我不熟悉的键盘布局或设备上。

此外，更重要的是，我并不经常信任所有软件开发人员。一旦我使用了包含空格的密码。某些服务后来更改了它们的身份验证方法，以便从密码中删除空格。这使我无法登录。

我担心其他符号也可能发生类似的情况，尤其是当我们考虑使用非ASCII符号时。顺便说一句，您的客户服务不鼓励使用特殊符号的事实充分说明了不应该信任特殊符号并且它们可能会做奇怪的事情的事实（无论现在还是将来）。

毕竟，如果您考虑数字，使用符号与在字母数字密码中添加几个字符没有什么不同：


100个符号（所有ASCII可打印字符），长度8：1008个组合；
62个符号（ASCII字母和数字），长度9：629个组合，大于1008。

使用更多符号会有所帮助，但增加长度会更好（kx比xk增长得更快。

#12 楼

正如@dr jimbob所说，您在密码!@£$%^&*()中使用的不可打印字符£。如果您从密码中删除了不可打印的字符£，则将接受该服务。这是因为密码加密是使用c或Java核心级别开发的，以保持较高的安全性。


使非技术人员很难使他们理解不可打印的内容字符。因此，客户服务主管要求您使用简单的字母数字而不是特殊字符。


请尝试使用!@$%^&*()更改您的新密码，该密码在经过在线发布测试后请进行更改。

简单来说，可接受的字符在ASCII 32到126之间

#13 楼

该特定序列只是按住SHIFT键并输入1234567890。因此，我假设他们不允许该特定序列，因为这对黑客来说很简单，很多人都这样做。例如，我看到人们使用QWERASDFZXCV来输入密码是不安全的，因为您只是按住shift键并向下移动键盘的左侧。

#14 楼

但是，密码和用户名通常都使用有限的字符。

在安全计算中，您会遇到一些攻击面，漏洞和利用。可靠性是分开的。

是的，更多的字符更加随机，但是您的攻击面也更大。

您可以创建有限字符集的足够随机的密码。
36 ^ 8 = 2,821,109,907,456对于大多数安全需求来说是足够随机的。如果不是，则将其提高到10或12个字符。您只能希望他们使用随机字符。该漏洞存在密码，您可以猜测FistNameLastNaveYYMMDD，其中YYMMDD是生日。

某些Unicode字符看起来相同。您可以创建一个变音符号作为单独的字符。这些字符不同：希腊Ο，拉丁O和西里尔字母О。

根据计算机上的字符集（代码页），您实际上可能会获得不同的映射。这个想法是跨字符集的安全的确定性字符集。

您需要考虑HTML编码，网络压缩，加盐等等。控制字符呢？

您必须在某些地方画线，事实是您不需要大的字符集即可创建足够随机的密码。

这与程序员懒惰或不足。这是关于提供可靠的可靠代码。使用受控字符集可以更好地测试所有可能性。如果在传输过程中发生了一些奇怪的事情，则可以使用一个较小的测试集来找出破坏它的原因。