发生这种情况的最可能原因是系统截断了密码。要检查这个假设，您可以尝试将密码更改为更长的密码，看看会发生什么：系统是否将“thisquitelongpassword”识别为“thisquitelong”？如果是这样，系统肯定会截断密码。如果不是，则输入验证可能存在严重问题，正如@Matthew 所强调的那样。

虽然密码截断可能是与遗留系统交互所必需的 - 这也会截断用户名，请参阅Serverfault 上的这个答案 - 通常应该避免它，因为它减少了“密码空间”，即可以生成的唯一密码的数量。

如果攻击者知道他们的目标系统使用截断密码，他们可以节省大量资源（时间、金钱），因为他们知道他们不需要尝试超过截断长度的密码。

虽然你的行为对我来说并不恶意，但一些组织对人们在他们的系统中发现缺陷非常敏感。

因此，您可以尝试将这一点告诉您的大学，但不要过分强调您对可能的攻击的了解。只是说“我读到这可能是安全问题的迹象”之类的话应该没问题。此外，不要以“这完全不合理”之类的绝对方式陈述事情，因为这可能是有原因的（对于密码截断，而不是错误的输入验证）。

显然，不要执行太多测试，不要自动化测试，不要进行攻击。

这可能表明正在使用的任何密码散列例程要么截断输入（仅使用密码的前 x 个字符），要么对正确密码的比较实施不佳，并且仅比较第一部分（这可能意味着用于存储密码的分组密码，或存储的原始密码）。

这两种情况都不是特别好。

在截断的情况下，它会给人一种错误的安全感——你可能选择了一个很长的随机密码，但如果实际上只使用了前几个字符，它就没有你想象的那么安全，因此可以更容易地在蛮力攻击中被猜到。我希望这是更可能的解释。

如果比较例程不佳，这表明负责身份验证例程的开发人员不熟悉安全开发实践。通过使用部分比较（例如SELECT * FROM users WHERE 'username' LIKE '$username%' AND 'password' LIKE '$password%'），它再次增加了蛮力攻击起作用的机会，但也表明可能已经犯了其他错误：在上面的示例中，潜在地设置密码a' OR 1=1'--会导致 SQL 注入攻击。显然，这是一个稍微做作的例子，但并不超出可能的范围。

在使用分组密码而不是密码散列算法的情况下，一旦加密，数据库中允许的长度可能不足以用于长密码。实际上，这是对加密数据的截断，而不是对输入的截断。但最终效果是一样的：提供长密码会让人产生虚假的安全感。