我正在使用一项在线服务，最近我因为忘记了密码而不得不重设密码。当我去更改密码时，我想使用带有符号的密码!@£$%^&*()。当我单击“确认密码”时，它向我显示“_Invaid Data”，我最终发现这是因为该符号。然后我与客户服务人员交谈并告诉他们这一点（以及将“_Invalid Data”替换为“密码只能包含字母和数字”），他们回复说“对不起，我们制定的指导方针是为了安全措施”。（这就是我听到的消息）
问题是为什么他们说当符号使密码更安全时允许在密码中使用符号是不安全的？
为了确保他们将来有更好的安全性，我确实对他们进行了教育，并说如果您有一个仅包含字母和数字的 8 个字符长的密码，它将允许36^8=2,821,109,907,456包含 12 个符号（!@£$%^&*()_+）的组合，它将允许48^8=28,179,280,429,056字符长，这意味着有额外的25,358,170,521,600组合，他们现在将这些信息转发给他们的经理。
这些“安全措施”不是为了您的安全，而是为了他们的安全。
连字符、撇号、百分号、星号、斜杠、句点等符号对攻击者执行“注入”攻击很有用，例如 SQL 注入、XPath 注入、文件路径注入等。通过阻止这些字符，网站所有者希望他们正在阻止您攻击他们的服务器。
他们可能应该更多地关注正确的数据处理，例如在内部使用参数化 SQL 和特殊字符转义，但这是一个额外的措施，可以帮助他们在网站中出现隐藏的编码错误时作为权宜之计。
我无法明确回答“为什么”他们这样做。也许他们有一位安全审计员说“使用列入白名单的字符集进行用户输入，并阻止任何非字母数字符号”。也许他们购买的网络包带有这个限制。也许他们的安全副总裁说“添加一些可见的措施，给我们的客户留下我们认真对待安全的印象。” 谁知道为什么？
问题是为什么他们说当符号使密码更安全时允许在密码中使用符号是不安全的？
您很可能正在与客户服务中的某个人打交道，他们不知道为什么要制定某些规则并得出结论，要么通过过去使用这个借口并取得结果，要么在他们的脑海中编造出来，这将使与他们打交道的人不会质疑而只是去做。
你的解释是正确的，通过添加符号以及字母、大写和小写字母以及数字，密码变得更加安全。
我会把它写成一个未经培训的客户服务代理，只是试图让工作更轻松，或者这个人知道该政策存在缺陷，只是想让这段对话尽可能简短。
因为他们可能使用input sanitation而不是参数化查询和output sanitation。
如果他们有参数化查询，这将不是问题。如果他们知道如何清理他们的输出，这将不是问题。
更有可能的是，他们的代码容易受到许多其他因素的影响，例如基于 unicode 的走私。对于许多“安全开发人员”来说，输入卫生只是从输入中去除撇号，这是一种非常糟糕的方法。
这不会防止基于 unicode 的走私，并且会干扰数据库中撇号的合法用途，例如人名。想象一下，试图在数据库中搜索某人的姓氏，但你不能，因为有一个撇号。那是愚蠢的。
正确的解决方案如下：输入验证（null > 长度 > 格式 > 白名单）** > **参数化查询>输出卫生（以避免 XSS），他们可能没有遵循。没有正当理由排除适当的数据。
同意您的分析，允许符号允许更高的安全性，但通常不会那么多。尤其是与使用稍长的密码相比（假设密码是完全随机选择的符号）。使用 95 个可打印的 ascii 字符中的任何一个：
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^_`{|} ~
（如果您将制表符或换行符等字符计为可打印字符，则更多）8 字符密码有 95^8 ~ 6.6 x 10^15 的可能性，而只有（区分大小写）字母和数字的 8 字符密码有 62^ 8 ~ 2.2 x 10^14 大约弱 30 倍。
但是，只有数字+小写+大写的 9 字符密码比允许特殊字符的 8 字符密码强两倍。因此，除非对密码的长度有硬性限制（实际上至少不需要对少于几百个字符的密码进行限制），即使使用有限的字符集，也很容易转向稍长的密码。
最大的潜在安全问题是他们是否认为允许密码中的特殊字符可能会导致其应用程序或数据库出现问题。\0排除可能导致问题的不可打印的 ASCII 字符（例如，ASCII 控制字符 NUL ( )、退格 ( ) 等）是有正当理由的\b，但设计良好的应用程序应该能够处理常规特殊字符，例如'或-不易受到注入攻击。应用程序应该能够处理这些类型的字符，例如它们出现在带有引号或连字符的名称中（例如，Conan O'Brien、Daniel Day-Lewis）。此外，由于不应将密码保存到数据库中或将密码返回给用户并立即进行散列处理，因此允许可打印的 ASCII 特殊字符无关紧要。
诚然，非 ASCII 特殊字符（如 unicode）存在一些可用性问题，出于可用性问题，禁止这些字符或以标准方式规范化它们可能是个好主意。散列函数通常需要一串字节，并且具有 ASCII 以外的特殊字符的密码可以在字节级别以不同的方式进行编码（例如，UTF-8、UTF-7、UTF-16、ISO-8859-1）。此外，除了不同的编码（您可以在应用程序级别保持一致）之外，您还必须担心外观相同的字母在 unicode 中具有不同的值。例如，下面的字符 Å 是unicode 00C5，但这个外观相同的字符是 Å unicode 212B而这个 Å 实际上是两个字符 - 一个带有unicode 030a组合字符的 ascii A，在 A 上添加了一个圆圈。
编辑：我刚刚注意到您将 £ 列为您的常见符号之一。不幸的是，这不是标准的 ASCII 符号。在 ISO-Latin-1 中，它是 byte A3。在 UTF-8 中，它是两个字节C2 A3。在 UTF-7 中，它是 ASCII 字符+AKM-。在 UTF-16 中是00 A3. 这些不同的编码意味着如果处理不当，您的哈希函数可能会在此字符上中断。当然，应用程序应该能够正确处理编码，但它可能会在某些设备子集上失败。此外，该字符可能在外国键盘上不可用。
某些应用程序/平台中的字符可能会出现可用性问题，'或者"在某些应用程序/平台中可能会被转换为智能引号‘’“”（尽管这绝不应该在密码上下文中完成）。
最后，拥有唯一密码规则还有一个额外的理由——让用户更难拥有一个可以在任何地方重复使用的记住密码，这是一种可怕的安全做法。如果用户的“正常”密码不符合某个站点的唯一规则，那么当他们的正常密码在某个随机的其他站点（即以明文形式存储密码）上被盗用时，他们的帐户不会在具有唯一性的站点上被盗用规则。