为什么不允许在密码中使用特殊字符？

#1 楼

我在这里没有看到的一种解释是，许多金融机构都与较早的系统紧密集成在一起，并且受到那些系统的局限性的影响。

具有讽刺意味的是，我已经看到了构建的系统为了与旧系统兼容，但现在旧系统已经不复存在，并且仍然必须存在该策略，以便与为与旧系统兼容而构建的新系统兼容。

（这里的教训是，如果您必须与旧系统兼容，请在将来消除这些限制）。

#2 楼

支持费用呢？假设我们允许任何人创建由€个字符组成的密码。欢呼，我们可以在密码中使用特殊字符。但是，等等-如果我们想通过手机访问银行，到底该如何输入密码？用键盘输入€比用手机输入要容易。

假期怎么样？我们在英国，只能访问英国键盘。代替€，我们可以轻松地键入£。单词easily在这里非常重要。对于一些普通用户而言，键入“新”键盘的字符可能是个问题。他将如何解决这个问题？他可能会致电银行支持部门，要求他们更改密码或询问why the € character dissapeared from his keyboard。

#3 楼

这可以（弱地）证明是纵深防御措施-如果存在注入或其他数据解释错误，限制密码字符集和长度可能会阻止其被利用。它还稍微简化了实现，因为如果它们仅处理7位ASCII字符，则Unicode和多字节字符串处理是无关紧要的，并且较简单的实现通常不太可能包含错误。

但是，评估这种降低的风险与降低密码质量所导致的风险增加之间的关系并不简单-我希望随着系统用户数量的增加，可能被泄露的密码数量也会随之增加，从而加大了对取消此类限制的投资值得。话虽如此，即使该字段完全不受限制，大多数用户的密码也会很糟糕。

#4 楼

我的猜测是该策略适用于所有用户输入的字段，并且为简单起见，将相同的用户输入策略（无特殊字符）应用于包括密码的字段。或者在某个时候，某些银行没有对密码进行哈希处理，而是通过其密码字段进行了SQLi攻击，因此决定了一项策略，规定密码不能包含特殊字符（一旦引入哈希，便会忘记该策略的原因）。 br />
绝对有安全优势，不允许在其他用户输入的字段中输入不经过哈希处理的特殊字符，这些特殊字符可用于各种攻击，例如SQLi或XSS（在查看帐户的银行管理员那里）。但是，通常可以通过在SQL中始终使用绑定参数并在显示/保存到db之前总是对用户输入进行清理来解决这些威胁。

我的另一个猜测是，他们希望拥有可能不同的自定义规则从其他地方访问，因此您不能轻易地重复使用标准的强密码（该密码可能会丢失），并且不得不为他们的网站提出一些独特的建议。


编辑：在其他地方我认为，根据语言的不同，我可以想到至少三个特殊的ASCII字符，通常应该禁止/剥离它们，因为它们只会诱惑命运。特别是：\r（null-ascii 0），因为它通常用于指示C风格语言的字符串结尾（可能用户在字符串结尾之后更改内存）。还有回车和换行符\n（ascii 13）和\r\n（ascii 10），因为无论换行符是\n还是,./<>?;':"[]{}\|!@#$%^&*(-=_+，它们通常取决于系统，这带来了不可避免的问题，我只能从Windows而不是Mac / Linux机器上登录。实际上，仅允许可打印的ascii（32-126）并禁止不可打印的ASCII 0-31和127似乎很合理。

但是，如果用特殊字符表示的是unicode而不是ASCII字符（如2b 41 38 41 2d，则从多个操作系统/键盘/浏览器简化实现似乎是合理的，不允许使用特殊字符。请想象您的密码中使用小写的pi。这是希腊pi吗？ （π）代表代码点0x3c0或科普特小写pi（ⲡ）代表代码点0x2ca1-只能工作一个，并且在Unicode中存在具有不同代码点的类似字符的这种类型的问题。能够将两个π等同，因此，如果您尝试在不同的位置登录，则可能会输入不同的字符。

类似地，尽管这个问题是程序员可以很大程度上控制并尝试进行纠正的，但允许使用Unicode字符会产生编码问题。也就是说，对于您的基本ascii字符来说，所有内容都以一个字节的数字表示。但是，对于编码unicode的方法有很多不同的方案。例如UTF-7，UTF-8， UTF-16，UTF-32，Latin-1（iso-8859-1），Latin-N编码，以及（对于某些编码）字节顺序（小字节序或大字节序）是什么？ pi（0x3c0）的Unicode代码点将表示为UTF-7中的字节CF 80，UTF-8中的FF FE c0 03，UTF-16中的FF FE 00 00 c0 03 00 00和UTF-32中的A1。您将无法用Latin-1表示pi（它只能包含95个额外的可打印字符），但是如果您的密码中包含¡ĄĦЁ‘ก”Ḃ且使用不同的编码，则可能必须使用以下任意字符q4312079q来表示pi （在某些拉丁语-N中可能是A1）。

是，网页可能已定义了字符集，但用户可以在浏览器中覆盖页面上的字符集，或者已从其他位置复制和粘贴了数据以不同的编码归根结底，禁止这些字符可能更简单。

#5 楼

概括地说，这是金融机构限制长度和字符集复杂度的最常见原因。
（1）Web服务是传统大型机应用程序的前端系统，通常具有八个字符限制仅由小写字母和数字组成。没有“特殊字符”。奇怪的是，这是最常见的限制。对上面的Mark Burnett +1。

（2）它们没有对密码进行哈希处理，因此它们不能简单地存储固定长度的数字字符串（即哈希输出-32字节的SHA256（password）） ）。因此，他们必须担心限制输入的大小。

（3）如果将密码存储为明文，则SQL注入威胁向量仅是密码问题。当组织通过存储散列密码（理想情况下使用PBKDF2之类进行加密和扩展）来解决问题时，许多组织和其他组织都在浪费时间担心转义密码字符。

除了支持简单的客户支持密码重置OVER安全性外，我不知道有任何可接受的理由可以从用户设备中以明文形式发送用户密码。您不希望承担责任，因此请不要接受。这就是加密散列的用途。

这是一篇很棒的博客文章，总结了一些最佳实践，并包括了代码示例。 http://crackstation.net/hashing-security.htm

评论

---

我不会考虑将密码散列为SQL注入的解决方案。如果您的代码在不对输入进行散列的情况下很容易受到攻击，那么您会遇到麻烦。并非所有输入都是密码。通过将绑定变量与准备好的语句一起使用，可以立即解决该问题。

–布兰登
15年4月22日在23:11

---

不过，在这种情况下，他特别是指密码。所以...哈希绝对是对SQL注入密码字段（与准备好的语句一起）的一种解决方案。

–凯尔·法里斯（KyleFarris）
15年5月6日在20:11

---

无论如何存储密码，都可以使用准备好的语句来阻止SQL注入。如果没有准备好的语句，则无论如何存储密码，都有冒险引入SQL注入漏洞的风险。密码不是SQL注入的问题。

–jordanbtucker
17年2月14日在5:03

---

#6 楼

我实际上问过一个大网上商店（bol.com，不确定它们是否是国际性的）。

他们的建议是使用强密码，经常更改它，使用字母和数字，应该是时间长了，也许还有其他我忘记的事情。无论如何，没有人遵循的通常建议。但是他们似乎在乎密码策略。

但是它们不允许使用大多数特殊字符，并且最大密码长度为12个字符。在询问后，他们告诉我，否则会有太多人与支持人员联系。

当我发回邮件询问他们“忘记密码？”的内容时，功能是针对我的，我没有回信...

因此对于银行来说，通过电子邮件进行简单的密码重置是不可能的，我想支持费用确实是原因（如其他人在这里）。对于像bol.com这样的任何其他网站，我将非常不信任它们是否会哈希密码。如果数据库泄漏您的密码将是已知的，则应在此处使用一个更独特的密码。

#7 楼

将字符集限制为字母数字可限制脚本或漏洞利用程序通过输入验证阶段的可能性。

用户始终可以使用更长的密码来提高安全性，但是应用程序需要具有特定的白名单以帮助防止攻击。

#8 楼

我可以尝试以UI界面设计师而不是程序员的身份来解决上面的问题：关键是登录要求部分是UI界面设计问题，而不是仅编程问题。

有一本很棒的书“ Apress-程序员的用户界面设计”，其中显示了与窗口大小相关的类似问题，我将在下面发布：


这是程序员常见的思维模式：只有三个
数字：0，1和n。如果允许n，则所有n的可能性均相同。
这种思想模式来自于旧的编码约定（可能是
smart），您的代码中不应包含任何数字常量
， 0和1。


现在，上面的想法在仅编程问题中是正确的，但是由于它涉及用户界面，尤其是Windows，因此不是


但事实并非如此。事实证明，可能性不大。
有很多很好的理由，为什么您希望窗口恰好位于屏幕的顶部（最大化屏幕空间），但实际上并没有任何理由留下两个像素在屏幕顶部和窗口
之间。因此，实际上，0比2更有可能出现。


现在出现了我们的问题，从编程和形式上看，从理论上讲，所有字符都应具有相同的可能性和均等的允许，但是在这里，我们也处于UI界面问题实例中，我们必须意识到这一点，并为其赋予正确的权重。

所以我从上面的线程中解释一个答案，我认为是正确：


假设我们允许任何人创建包含€
char的密码。祝您好运，我们可以在密码中使用特殊字符。
但是，等等-如果我们想通过手机访问银行，该如何输入密码？键入€
更容易从我们的键盘而不是从手机。


从可用性的角度来看，这是主要观点，如果他在几年后意识到使用智能手机，就不应将其归咎于用户在甚至还不存在几年之前，他就使用了应该避免的角色。

考虑这类问题并让用户避免它是我们的义务！

#9 楼

开派对有点晚-我最近读到，原因是对于许多银行来说，实现这些字符所增加的安全性的价值超过了实施成本和与无法记住密码的客户打交道的支持成本。 。

我并不是说这是一个很好的理由，但这就是我解释所读内容的方式。

http://www.theglobeandmail.com/technology/digital-culture/why-canadas-banks-have-weaker-passwords-than-twitter-or-google/article18325257/

#10 楼

还有一个原因！一些特殊字符会根据使用的键盘更改其位置。例如，在US-EN和日语键盘混合环境中，at标记（@）和星号（*）位于不同的键上。如果我每次因用户使用错误的键盘方案而被锁定而要给我一角钱...好吧，我约有一美元左右，但是您明白了。