example@gmail.com，我的电子邮件前缀example@gmail.comm等。然后我还尝试拼写错误的密码，只要它与我的真实密码相差不远，我就可以登录（使用密码时，在真实密码之前或之后添加一个随机字母，但在中间添加字母时无效）。
我还检查了请求中发送的实际数据在Chrome DevTools中查看它，实际上是发送了错误的数据。
怎么可能？我应该担心我的帐户的安全性吗？
#1 楼
Facebook允许您犯一些错误，以简化登录过程。 Facebook工程师在会议上解释了该过程。要点是，Facebook将尝试对您提交的输入进行各种排列，并查看它们是否与数据库中的哈希值匹配。例如，如果您的密码是“ myRealPassword！”，但您提交“ MYrEALpASSWORD！” （启用大写锁定，将反转大写锁定）。提交的密码显然与他们存储在数据库中的密码不匹配。 Facebook并没有拒绝您，而是试图通过尝试“纠正”一些常见错误来提高用户体验，例如在前后插入随机字符，大写（或不包括）第一个字符或错误地使用大写锁定。 Facebook会一一应用这些过滤器，并根据它们在数据库中哈希的内容检查新的“更正”的密码。如果其中一个排列匹配，Facebook会假定您只是犯了一个小错误并授权了会话。虽然乍一看令人担忧，但出于某些原因，这实际上仍然是完全安全的。首先，Facebook能够做到这一点而无需以明文形式存储密码，因为Facebook会从表单字段转换您提供的（和不受信任的）输入并检查是否匹配。其次，这对于试图强行使用密码的人不是很有帮助，因为由于速率限制和验证码的原因，在线攻击几乎是不可能的。最后，攻击者/恶性配偶知道您的密码而不是大写的几率很小，因此，由于此功能而造成的风险也很小。
您应该担心？不，可能不是。
进一步阅读：https://www.howtogeek.com/402761/facebook-fudges-your-password-for-your-convenience/
评论
评论不作进一步讨论；此对话已移至聊天。
–Rory Alsop♦
19年8月15日在12:44
创建密码时了解这一点将有所帮助。例如，就安全性而言，这至少看起来使大写变得无用/无关紧要，因此您最好也不要使用它-这样可以节省一些脑力。
–克里斯·莫斯基尼（Chris Moschini）
19-10-5在14:49
@ChrisMoschini，除非您仅将第一个单词大写-我完全不同意。正如答案中所解释的，facebook尝试使用倒置的大写锁定密码，因此，以他的示例为例，如果您发送“ myrealpassword”或“ MYREALPASSWORD”，则它将无效。
–Cássio Renan
19-10-12在0:47
同样值得注意的是，Facebook默认使用多因素身份验证。在此特定实现中，密码的在线攻击弹性并不像在真空中那样重要。
– Monica辩护律师走出去
19-10-16在16:34
#2 楼
众所周知，Facebook允许您故意以相反的密码大小写或首字母大写的方式登录（请参阅本文）。他们在仅存储哈希密码的同时执行此操作。您看到更多的差异了吗？显然，它们也具有一些相似的电子邮件地址可用性功能。
将gmail.comm自动“更正”为gmail.com实际上是无害的，由于（目前）没有comld tld，因此实际上没有人会拥有有效的gmail.comm电子邮件地址。不过，令我感到惊讶的是，他们允许gmadil.com（当前正在出售）或其他用户名，因为这可能是其他人的电子邮件地址。
他们可能已经决定可用性非常重要，并且，如果尝试登录没有该帐户的电子邮件地址，则自动尝试使用最相似的用户名登录，但是-并不完全糟糕-这似乎不是一个好方法，因为其他人可以明天用
ezfxample@gmail.com电子邮件进行注册，虽然不太可能，但也使用Password123作为密码，那又如何呢？ ？并且显然只有在您未从上一个会话中删除Facebook cookie的情况下，使用拼写错误的电子邮件地址登录才有效。因此，只有在知道您曾经以example@gmail.com身份登录时，它才会自动更正您的电子邮件地址，否则会失败。部分内容，但现在已删除了答案。评论
gmadil.com实际上不是在出售。这是比利时的一个恶意域名。
– Nzall
19年8月7日在9:07
“他们通过存储密码的不同哈希值来做到这一点”-需要引用。我认为他们更有可能采用提供的密码的纯文本形式，对其进行哈希处理，然后检查是否是所存储的哈希，然后反转首字母的大小写，对其进行哈希处理并进行检查，等等。存储多个哈希将如果密码数据库泄漏（因为攻击者可以散列一次并与多个值进行比较），则使暴力破解变得容易得多。
–马丁·邦纳（Martin Bonner）支持莫妮卡（Monica）
19年8月7日在10:55
除了@MartinBonner的反对意见之外，存储多个哈希也将使对算法进行更改变得更加复杂，因为该算法将计算允许使用的密码变体集-因为将无法计算任何新的哈希或确定哪个直到用户下次登录并提供密码为止。仅散列所有可能的可能性，同时大概承担非常低的性能成本，实现起来就容易得多。
–马克·阿默里（Mark Amery）
19年8月7日15:29
@MartinBonner（和@MarkAmery）：公平点。我想指出的是，他们没有为此存储明文密码，但是有多种方法可以实现该目的。我已经编辑了答案，使声明更加开放。
–Ángel
19年8月7日在20:50
是的，在相似的地址处可能有一个匹配的用户名，但是该电子邮件地址的所有者也不太可能会与您的密码匹配。 （除非您当然都使用了通用的不安全密码。）
– WGroleau
19年8月7日在23:59
#3 楼
如果您从整体上考虑登录过程，则此措施实际上可以提高安全性。该网站没有授予用户几次登录尝试手动修复常见的拼写错误，而是尝试自动修复这些拼写错误。结果，用户所需的平均登录尝试次数减少了，这意味着对尝试各种常用密码的攻击者（而不是同一密码的细微变化）的攻击者，将进行更严格的限制。评论
您可能夸大了您的案子。此过程有助于识别真正的随机蛮力尝试。
– schroeder♦
19年8月21日在11:09
@schroeder对不起，我不明白。修复常见的拼写错误意味着在限制速率之前减少登录尝试。速率限制可防止基于蛮力和字典的密码猜测。缓解密码猜测可提高整体安全性。
–德米特里·格里戈里耶夫（Dmitry Grigoryev）
19年8月21日在11:36
这不会减轻所有密码猜测的可能性，而会减轻某种密码猜测的方法。因此，我不确定您是否可以说它可以提高整体安全性。
– schroeder♦
19年8月21日在11:38
@schroeder将需要统计数据来证明它是否确实提高了安全性。当然，如果不严格限制速率，也不会有任何改善。我要说的是，通过这种措施可以提高安全性。
–德米特里·格里戈里耶夫（Dmitry Grigoryev）
19年8月21日在12:26
@schroeder还会不需要更少的尝试来猜测密码，从而降低安全性吗？
–地上
19-10-4在2:02
评论
如果为真（并且有足够大的声称我将要独立进行验证），那么是的，每个人都应该担心帐户安全性，因为这意味着密码以可逆的形式存储。@Ghedipunk更精确地说，它在真实密码之前和之后添加了一个随机字母。在中间添加一个随机字母不允许我登录。
这是一个重要的区别，随机字母位于命令之前或之后（并感谢您也对问题进行了澄清说明；它会有所帮助）...可以进行检查，而无需以可逆形式存储它。由于它们允许像这样的一些虚假因素，是时候让我生成更长的密码了，尽管... ;-)
它只是使熵降低了一点。
相关：security.stackexchange.com/q/122848/59741和security.stackexchange.com/q/68013/59741