某些网站不允许在密码中使用句点是否有原因？答案

【问题标题】：Is there a reason why certain sites don't allow periods in passwords?某些网站不允许在密码中使用句点是否有原因？
【发布时间】：2010-10-18 13:56:53
【问题描述】：

我只是想知道为什么某些网站不允许在密码字段中输入字母和数字以外的任何内容。

是否存在安全原因，或者可能只是他们使用的数据库的限制？感谢您的信息。

编辑：Oracle 的数据库似乎不承认大写和小写？这是真的？是通过 PM 告诉我的。谢谢大家提供的信息，这真的很有用。

我想知道为什么这个问题需要 3 票才能结束。没有足够的 jQuery 和手绘圆圈？

【问题讨论】：

我倾向于不信任有这种要求的网站。 “你如何存储我的密码，这样的要求甚至很重要？”是一种常见的反应。
@Frus：超级用户更像是一个最终用户网站，而不是一个编程网站。由于这个问题是专门询问这个选择背后的编程原因，所以它属于这里。
不是真的，这是与编程相关的，并不是最终用户或网站管理员需要回答的问题。我想要具体的编程原因。
有太多的选择去哪里 - 很难确定一个问题是否属于。三部曲已经够糟糕了。它逐渐变得越来越难。
这怎么跑题了？据我了解，他不是在问这与网站所有者的个人偏好有何关系，而是在问这样做是否有一些编程原因。

标签： database security

【解决方案1】：

一般来说，他们脑残而且害怕标点符号 - 点也算标点符号。这更像是“友军开火”，而不是 dot 是危险的。 Dash 也相当无害。

其中一个问题当然是SQL Injection。另一个是编程人员的能力。

【讨论】：

在以前的工作中，我们自己的系统有这样的要求（例如，我曾经在一家银行工作，只允许用户密码中包含字母和数字），这通常是“这就是什么”的问题我们购买的第 3 方系统/小部件/解决方案需要。”所以有时“能力”问题会追溯到决定购买它的人（通常不是程序员）以及他们从谁那里购买它。
Chase 就是其中之一。令人难以置信的是，像 Stack Overflow 这样的网站如何允许我配置比我的 banking 网站更安全的密码。叹息
如果密码中的标点符号成为 SQL 注入问题，他们做错了。

【解决方案2】：

我曾在一个希望能够通过电话读取密码的地方工作（这就是提供支持的方式）。支持人员不知道符号的所有名称（散列、砰、管道、与号/和、星号/星号）和其他问题（您指的是哪个左括号、哪个引号等）。所以他们不允许任何标点符号。

不是一个很好的理由（支持人员不应该知道我的密码），但你并没有仅仅因为充分的理由而要求 :)

【讨论】：

这是一个很好的理由，也是消除某些符号的有效理由。不仅支持的任何人都应该知道您的密码，而且当有人可以访问您的帐单详细信息（CC 号码、帐单地址）、修改您的帐户或可以物理访问您的机器（或托管您的内容/服务的机器）时，您我们对他们的信任远远超过了您的帐户密码所保护的内容。也就是说，大多数网站从不需要这样做，因为通过电话或亲自进行互动极为罕见。
（我应该提一下你永远不应该在多个地方使用相同的密码吗？）
@Roger Pate：我使用了一个很好的系统，密码的中心体相同，但根据网站的不同，四肢不同。效果很好，怀疑有人会立即注意到一种模式。
@Sergio：这很常见，但除非您知道有关如何为每个站点管理和存储密码的详细信息（而您不知道），否则您不能相信它可以保护其他密码。除非转换显然是单向的，否则我不会使用它，但通常这会消除大多数人在头脑中找出密码的好处。相反，我使用唯一的密码并在 KeePass[X] 中管理它们。

【解决方案3】：

根本没有理由，除了草率的 DB 编码，他们允许在 DB 中使用纯文本或使用（非便携式）DB 函数来散列密码并使用直接 SQL 语句。这看起来就像普通的字符串验证。

除此之外，在实用方面，特殊字符放置在外国或狭窄的键盘中很棘手，并且可能会让正在旅行的用户更加沮丧（或者在更现代的情况下，替代输入，如智能手机上的屏幕键盘）。一些网站甚至可能通过提供自己的屏幕键盘来进一步推动系统登录（带有各种加扰）。

禁止特殊字符有助于 QA，并减少多平台用户的挫败感。

最后，允许有限的（被认为是安全的）字符集（不仅是标点符号，还有更多 Unicode 中特定于语言的字符），开发人员还可以避免浏览器和服务器应用程序之间的编码混淆（表单数据编码不是标准中非常清楚，在某些浏览器上可能会很棘手）。

【讨论】：

允许特殊字符并不一定意味着需要特殊字符。如果用户知道他们将登录的系统很难输入这些字符，那么明智的解决方案是不使用这些字符。
在一个理想的世界里，用户当然会知道，但在一些非常一般的情况下（95% 的情况），那是因为移动网站是在之后添加的，还是用户没有例如，在旅行之前了解外国键盘布局。
禁止使用某些字符，因为一些用户可能访问可能无法轻松输入这些字符的网站——以及那些用户可能不知道如何解决这个问题 - 会很奇怪。
可能会引起一些挫败感，并且该网站的目标尚不清楚，而且我提到了移动网站的输入可能更有限/令人沮丧，或者最糟糕（视频游戏系统）。
我从来没有在任何键盘上找到句号。

【解决方案4】：

没有可能的原因。他们只是无能。任何关于 SQL 注入或其他任何事情的担忧都是错误的。这只是告诉您他们担心可能的安全注入，因为他们没有散列或加密您的密码。

【讨论】：

除了技术问题外，还有其他问题。有关示例，请参见 user479383 评论。一般来说，您是在做一个需要证明的一般性陈述，而不仅仅是可能提出的案例的示例。

【解决方案5】：

关于大写/小写：如果您以纯文本形式存储密码，那么这可能是个问题。我不确定 Oracle，但 SqlServer 认为“密码”和“密码”是相同的。

如果您将密码存储为哈希，那么原始的大小写不是问题：密码区分大小写。

【讨论】：

【解决方案6】：

OWASP 在这个问题上非常清楚。它在OWASP Passwood Storage Cheat Sheet 中的第一条指导是：

不要限制字符集并为凭据设置较长的最大长度 一些组织限制 1) 特殊字符类型和 2) 系统接受的凭据长度，因为它们无法防止 SQL 注入、跨站点脚本、命令注入和其他形式的注入攻击。这些限制虽然是出于好意，但有助于某些简单的攻击，例如暴力破解。

不允许使用短密码或无长度密码，并且不对凭据的输入或存储应用字符集或编码限制。继续应用编码、转义、屏蔽、完全省略和其他最佳实践来消除注入风险。

一个合理的长密码长度是 160。很长的密码策略在某些情况下会导致 DOS1。

【讨论】：

【解决方案7】：

不就是避免所有可能的SQL injection吗？

【讨论】：

@Goto，. 怎么会有允许 SQL 注入的危险？ --、;、'，SQL 关键字会更危险。
我怀疑';DROP TABLE Users;--
@Goto：为什么会有'。'启用 SQL 注入？
他们可能认为这样更安全，但是限制输入字段中的字符并不是解决SQL注入的正确方法。见bobby-tables.com
可能，但不允许在用户名中使用某些字符则表明开发人员要么懒惰，要么不知道如何正确防止此类攻击。