2FA 的一次性恢复代码不会引入后门吗?

信息安全 密码 密码管理 多因素 一次性密码 后门
2021-08-10 17:32:35

尽管使用多因素身份验证显然是一个不错的举措,但我正在为“一次性恢复代码”的概念而苦苦挣扎。在我看来,如果您选择使用它们,您正在做的是在前门上增加额外的安全性(如螺栓和挂锁),使其更难以这种方式打破,但在前门安装一个纸薄的后门同时!

这些“一次性恢复代码”:

  • 像万能钥匙一样,但由于它们只是几位数字,它们不是“强”密码
  • 必须存储在“提供者”端,因此如果提供者的系统受到威胁,您将很容易受到攻击
  • 必须以某种方式存储在本地(1),引入另一个漏洞

(1) 我看到 StackExchange 上有几个线程已经讨论了这一点。

完全禁用“一次性恢复代码”不是最好的做法吗?(假设提供商的系统实际上允许您在设置完成后这样做......)。

4个回答

tl/dr:一次性恢复代码为帐户所有者提供了重新获得失去访问权限的选项。认为这是一个额外风险的人总是可以忽略或销毁它,但担心失去对关键服务的访问权的人当然可以想出一种安全的方式来存储它。因此,对于可能对企业和/或个人至关重要的服务来说,这是一个不错的选择。

没有安全的

在我见过的大多数具有一次性恢复代码的系统中,它们是一项可选功能。结果,它们为帐户所有者提供了一种减轻竞争风险的方法。

谈到安全性,请务必记住,没有“安全”之类的东西,只有“对我来说足够安全”。不同的公司和个人有不同的风险承受能力、不同的威胁模型和不同的关注点。

缓解拒绝服务漏洞

从这个角度来看,一次性恢复代码是针对一种非常特殊的拒绝服务漏洞的缓解措施:故障(人)内存。在某些服务中,如果您丢失了密码,您将被永久锁定在您的帐户之外。在某些情况下,您可以通过获得一个新帐户并忍受不得不重新设置它的不便来解决这个问题。在某些情况下,这可能会破坏您的业务。如果特定帐户属于后一类,那么您可能不想冒忘记密码和失去访问权限的风险。

一次性恢复代码显然旨在解决该问题(以及可能导致您无法访问的其他类型的事件)。您可能会决定在一张纸上打印一次性恢复代码并将其放入(例如)银行保险箱中,这是一种在不增加帐户被盗风险的情况下降低帐户访问权限丢失风险的好方法。

再说一次,您可能决定您不担心失去帐户访问权限,因此您可以从站点“打印”一次性恢复代码,然后立即将其丢弃/烧掉/从不实际写下/从不实际请求首先是它。毕竟,如果您没有它,那么您不必担心不小心泄漏它。在这种情况下,您认为通过恢复代码增加的帐户被盗风险不值得拥有其他访问方式。

从服务提供商的角度

关键是您可以决定是否要使用此功能。我见过的许多网站都将其设为可选,但即使不是,您也可以轻松地销毁它。但是,作为服务提供商,如果我提供的服务可能对经营业务至关重要,那么我可能会有一些客户希望在帐户锁定的情况下获得替代访问方式。因此,提供这个选项对我来说非常有意义。

当然,当我开始收到声称无法访问其帐户的人发来的疯狂电子邮件时,这将为我省去很多麻烦。区分“我无法访问我的帐户”和“我正在尝试使用社交工程来说服支持人员让我访问其他人的帐户”之间的区别可能会非常棘手。如果我构建的选项可以让我的客户有自助选项来恢复他们自己的帐户,那么我需要处理的支持请求就会减少,并且我的法律责任也会减少(因为如果我不小心将帐户泄露给攻击者,我肯定会承担责任)。

此外,由于这些功能很少使用,因此提供商可以围绕它进行额外的保护。你肯定会保护人们试图暴力恢复代码,尽管我认为这不是一个真正的问题。我见过的每个恢复代码都足够长且随机,以至于它们无论如何都不会受到蛮力的影响。但总的来说,这个概念本身是完全有效的。特定提供商是否可能已经实施了一次恢复代码的不安全实施是另一回事。

最后,添加恢复代码不会让提供商更容易访问您的数据。 无论如何,提供商已经可以这样做,并且如果执法部门要求,无论您是否有恢复代码,都会这样做。对于旨在使提供商无法访问您的数据的服务(例如密码管理器),他们将设计恢复代码,以便提供商也无法访问它们。因此,恢复代码通常不会为内部攻击者创建额外的风险向量。

密码恢复一直是一个安全漏洞,因为目标是允许在不知道密码的情况下对帐户进行操作。受控系统中,您必须去管理台,告诉他您丢失了密码,并让他大喊您是一个愚蠢的男孩/女孩。最后,在确认您确实拥有合法访问权限后,管理员(真人)不得不手动重置密码。

这被认为是安全的,因为管理员已经清楚地识别并验证了请求来自合法用户。

但在大型网站或应用程序中,用户自行注册,并由人负责识别用户并确保密码重置请求实际上来自合法用户,这根本不可行。因此,网站所有者必须想办法让用户在忘记密码时恢复他们的帐户。

最常见的方式是通过邮件发送限时令牌。如果用户注册了该恢复电子邮件地址,他们应该拥有它,并对其安全负责。不幸的是,它不能用于主邮件帐户(除非用户有一个安全的辅助帐户)。

最糟糕的方式是密问因为认识用户的人可以猜出答案。或者可以在社交网络上搜索后猜测。并且可能会出现拼写问题(我使用的是 NEW YORK、NEW-YORK、New York 还是 New-York?)。众所周知,这允许从公众(例如 Sarah Palin)窃取帐户。

所以网站所有者以一次性恢复密码结束。这确实是一个糟糕的解决方案,降低了帐户的安全级别。但这可能不是最糟糕的方式。告诉你的用户(他们是你的客户,也就是那些让你赚钱的人)如果他们愚蠢到忘记密码,那么你不希望他们成为客户,这可能不是发展业务的最佳方式...

不,这不是后门

后门,在计算机安全中,指的是一种内置机制

  1. 被授权访问系统的个人在不再被授权后继续访问系统
  2. 无权访问系统但对系统有一定程度间接控制权的个人(例如,他们编写了代码)以访问系统

您谈论的场景是备用身份验证器,而不是后门。

但它安全吗?或许

您的问题(以及许多评论)都集中在“但它可以被蛮力强迫吗?” 嗯……这很复杂。

在线暴力攻击需要多次尝试才能成功。这些尝试必须发生得足够快,这是现实的。例如,在一个需要 1000 次尝试才能成功但每年只允许进行一次身份验证的系统中,并且受保护的资源在 100 年后将不再具有任何价值,则该资源是足够安全的。

当你进行计算时——而且你必须进行计算——你必须评估整个系统。

  1. 受保护数据的价值是什么?
  2. 受保护数据的价值会在未来某个时间到期吗?
  3. 如果预言机——你测试你是否拥有正确密码的东西——是一个实时服务器(或服务),它能让你多快执行攻击?
  4. 如果有多个用户可以访问系统,其中有多少人有恢复密码?需要多少个恢复密码才能以足够快的速度成功获取仍然有价值的数据?
  5. 还有其他补偿控制吗?与恢复尝试期间所需的其他(链式)身份验证一样,NOCC 会通过强制调查发出警报吗?身份验证所需的其他身份验证器(其他因素)在以其他方式验证帐户之前会话的生命周期很短?受限的“恢复访问”不能让您完全访问所有数据?“恢复”操作可以与恢复密码一起使用的高度受限的时间范围(您没有指定这是帐户恢复还是登录到特定的损坏服务器,或其他)?

你有一些假设在所有情况下都不正确

像万能钥匙一样,

不,它们就像密码一样。

但由于它们只是几位数字,它们不是“强”密码

您假设需要特定的强度,但强度取决于很多,如上所述。

必须存储在“提供者”端,因此如果提供者的系统受到威胁,您很容易受到攻击必须以某种方式在本地存储 (1),从而引入另一个漏洞

所有的身份验证机制都要求提供者存储一些东西。密码需要哈希。哈希链需要链中的前一个哈希。证书需要 CA 证书。私钥需要公钥。

为什么你认为它必须以这样的方式存储,如果泄漏它会完全被冲洗掉?为什么您认为它不能以与另一种机制相同的方式存储?是什么让您认为身份验证协议正是密码的协议,而不是某种形式的加密安全质询响应?

他们确实引入了后门,但这就是重点如果他们用于 2FA 的设备出现故障,他们还应该如何重新获得对其帐户的访问权限?通过联系帐户提供商并很好地询问?我们试过了,骗子喜欢它。

恢复代码是解决此问题的唯一实用方法。拥有完美安全性的唯一方法是拥有一个硬件不会出现故障的完美系统,这显然是不可能的。

无论如何,没有理由过度关注这些代码。它们可能成为安全风险的唯一方法是用户泄露它们(这是用户的问题),或者攻击者获得对安全提供商核心系统的直接访问权限,在这种情况下,恢复代码泄露是该提供商问题中最少的。