允许任何密码有什么安全隐患（如果有的话）？

Question

正如Ars和许多其他人所指出的那样，即使是拥有广泛的，可能是智能IT部门的大型组织也会使用密码创建规则，这些规则并不总是符合安全的最佳利益。

有时候，仍然很难理解为什么某些应用程序限制某些字符但允许其他字符串，以及为什么其他应用程序具有与所有其他应用程序形成对比的规则。所有这些让我觉得我错过了什么。

我被教导永远不要相信来自用户的原始输入，所以允许来自用户的输入而不是验证它是错误的，但是我感到矛盾。在这种情况下，我觉得有一个强有力的论据允许用户输入任何东西，而不是验证它（因为没有必要）。

出于说明的原因，请采用以下假设的用户注册系统：

假设用户注册系统

1. 用户导航到用于在网站上注册帐户的表单。
2. 在其他输入中，系统会提示用户输入密码。用户被告知他们可以输入任何所需的密码。没有规则。它绝对可以是任何字符串。
3. 收到提交的表单（或任何合法或恶意请求）后，服务器不会验证密码字段：它只是散列所有内容。
4. 哈希值存储在数据库中供以后使用。

例如，在PHP中：

password_hash($_POST['password'], PASSWORD_DEFAULT);

如果有，这个系统有什么安全隐患？

是否存在任何可能提交的特殊要求，以致在此系统中会产生意外后果？如果是，请提供示例。

某些服务器端语言是否容易受到攻击，但其他语言不受此类攻击？哪些？

同样，这个系统是说明性的。请不要争论这样的系统在其用户的安全性方面可能具有的优点或缺点。密码本身，只是它可能对系统本身产生的安全隐患。

Answer 1

阻止某些字符的最常见原因是开发人员不知道如何正确处理他们正在使用的任何语言的密码，而不是学会这样做，他们试图限制他们接受的数据（通常不正确地）。或者，他们依赖于错误处理密码的第三方组件，并认为他们无法解决此问题。 （这在您链接的文章中有所描述。）

如果代码正如您所描述的那样，中间没有花哨的JavaScript接触输入，没有中间件解压缩数据结构，没有日志系统编写密码，没有将原始密码写入数据库，没有SQL查询构建为字符串可能包括密码，数据库中没有未加密码的密码，URL中没有错误编码的字符串等等，那么是的，它很棒。它几乎是完美的（我更倾向于在发布到服务器之前应用一些散列，但是无论哪种方式都有一些参数）。

在现代应用程序中，开发人员将上一段中提到的所有内容拼凑在一起，然后应用一层希望和祈祷，然后在有人发布漏洞利用时争抢补丁。最后一段中的所有内容都很糟糕，也很常见。

因此，如果您看到对可接受的字符的限制，则意味着密码处理系统构建不佳或开发人员不信任它。这很常见，所以限制很常见。