总体而言，该协议似乎并未比现有技术增加安全性。如果您正在寻找在线保护您的身份的最佳方式，那么这是毫无疑问的。但是让我们回顾一下利弊：

好处

狭义的“共享”密码是不可能的，即恶意网站无法使用提供给一个站点的身份验证来登录另一个站点。

针对身份验证令牌的暴力攻击是不可行的。

凭据不会存储在您的计算机上。这可以保护您免受一小部分针对工作站的攻击。具体来说，您可以免受从您的计算机中窃取密码的攻击。但是，您不会受到任何类型的会话劫持或浏览器接管攻击的保护，而且您现在也容易受到与电话相关的攻击。稍后再谈。

缺点

这种技术很容易受到 MITM 攻击和社会工程的影响。可能比使用中的任何其他身份验证方案（包括密码）更重要。身份验证步骤和登录启动步骤本质上是断开的，因为手机将针对任何呈现的 QR 码正确地进行身份验证，无论它以何种方式或在何处呈现给用户。

因此，例如，网络钓鱼站点可以显示真实的登录二维码，该二维码登录攻击者而不是用户。Gibson 相信用户在身份验证期间会在手机应用程序上看到银行或商店或网站的名称，因此会保持足够的警惕来阻止攻击。历史表明这不太可能，更合理的预期是，在应用程序上看到正确的名称会错误地让用户相信该网站是合法的，因为它能够在手机上触发熟悉的登录请求。用户头脑中关于密码安全的谨慎态度并不一定会转化为像这样的新身份验证技术，这使得该应用程序可能天生对社会工程的抵抗力较低。

这种技术将身份验证和身份结合到一个经常丢失或被盗的物理对象中。 从这个意义上说，它更像是护照而不是密码。任何拥有您手机的人突然完全拥有您的身份：攻击者不仅可以冒充您，而且在第二部手机上没有第二份副本（不太可能），现在您已经失去了识别自己的能力。身份验证密钥不可撤销，因此如果没有从每个站点进行带外恢复，您将无法恢复您的身份。即使存在带外恢复，当面对两个用户时，一个拥有身份，一个没有身份，可能很难理解为什么站点运营商应该信任您。

此技术将所有身份验证令牌组合到一个密钥中，除非您手动创建其他令牌。这使您的一键成为攻击者的额外目标。此外，密钥存储在您的手机上，这些设备通常具有可笑的内部安全漏洞。将异常多汁的目标与不合标准的安全性结合起来并不能使您安全。

备择方案

该方案最有问题的方面是它与可用的替代方案相比有多差。

今天最安全的普遍接受的选项是 lastpass、keepass 和其他此类与浏览器集成的密码系统。特别是，客户端加密减轻了信任任何第三方的需要。更重要的是，浏览器集成使网络钓鱼几乎不可能。LastPass 或 KeePass 只会在从正确的域提供密码时填写密码，这意味着如果出现恶意站点，用户将无法访问他的密码。

此外，LastPass 最近添加了一项功能，该功能会提醒用户更改并非全球唯一的密码。这有助于防止密码重复使用，这意味着 Gibson 技术的主要好处可以很容易地在现有网站上使用此工具获得，而不会增加他的方案所暗示的不安全性。

使用手机或类似设备的现有第二因素身份验证方案有助于保护用户登录，现在已经这样做了，如果您的设备被盗，您不会立即受到身份盗用的影响。双重身份验证的附加安全性在于，如果设备和密码在没有对方的情况下被盗，则两者都无法使用。Gibson 的技术在很大程度上抵制被包含在双因素方案中，这使得这种保护级别不可用。

TL;博士：

Gibson 的身份验证技术并没有创造足够的优势来克服它也强加的额外安全成本。这些成本是方案本身的一个基本部分，如果不取消整个设计，就不可能计算出来。

你可以争辩说它总比没有好，但你不能争辩说它比我们已经拥有的任何东西都要好。

吉布森的更新

Gibson 最近宣布了一些针对网络钓鱼的额外保护措施，因为这是一个主要的批评。他们的保护是这样的：如果您不使用二维码、手机等，而是在您的系统上安装了身份验证代理（例如，在浏览器中），那么服务器可以检查以确保身份验证响应来自与身份验证请求相同的 IP。这很好，但该协议的全部目的是将您的身份转移到您的手机上。如果使用该协议的唯一安全方法是不使用它的核心功能，那么也许我们应该重新考虑我们要完成的工作。

从理论上讲，当（且仅当）您的手机知道它使用与您的计算机相同的 IP 时，您可以继续使用您的手机。当然，它无法知道，因为它不知道您计算机的 IP 地址。

更好的解决方案

如前所述，如果身份验证措施在您的浏览器中，那么整个网络钓鱼问题会立即得到解决，而无需用户进行任何努力或验证。即使是能力最差的用户也不会被欺骗到错误的站点进行身份验证，因为该站点的身份验证令牌与域名相关联，并且浏览器不允许对错误的域进行身份验证。这是一种今天已经在使用的技术，是完全自动的，不需要网站的合作或用户的任何智能。

可以通过要求第二个身份验证因素（例如手机上的随时间变化的密钥）来加强此方法，该因素同样已经可用并在今天使用，它可以保护您（最显着）免受部分错误的影响目标站点或公司的名称。

至于对浏览器端身份验证易受客户端工作站攻击的担忧：虽然这是真的，但如果您的浏览器受到威胁，那么无论您使用哪种身份验证机制，使用该浏览器都不是安全的。恶意软件作者可以（并且已经这样做）等待您使用您的超级安全技术自行进行身份验证，然后静默发送必要的流量以“拥有”您的帐户，所有这些都不会让您发现任何问题。SQRL 和任何其他身份验证系统都无法保护受感染浏览器的用户，就像门锁可以保护您免受房屋火灾一样。购买防火锁不是解决方案。

下一步在哪里

如果您正在寻找防止假冒的绝对保证，请查看 Fido U2F 令牌。该标准在 SQRL 不足的地方大放异彩，并保证您免受 MITM（例如网络钓鱼）攻击。它不仅对用户进行身份验证，还对通道进行身份验证，因此您可以保证 (a) 您的帐户在没有令牌的情况下无法通过身份验证，并且 (b) 您的令牌只能用于对连接进行身份验证到它所连接的机器上。有关更多信息，请参阅此答案。

SQRL 当然不是没有缺陷，但在安全性和（这很重要）可用性方面，它肯定优于当今网络上广泛使用的大多数主要身份验证解决方案。请允许我解释一下。

误解

首先，让我澄清一些关于这个问题的其他答案中存在的一些误解。其中许多答案已经过时，并且是在对解决其中提出的问题的 SQRL 文档进行更改之前编写的，而其他人似乎过分强调 SQRL 中的缺陷，这些缺陷也存在于许多其他广泛使用的现有身份验证解决方案中，而无视它的好处。那么让我们在这里澄清一些误解，好吗？

误区：SQRL需要扫描二维码才能工作

这根本不是真的。QR 码是一种便利，它使 SQRL 更易于在用户尚未设置 SQRL 客户端软件的计算机上使用。SQRL 的网站声明如下：

三种方法。. . 智能手机可选：

尽管开发该系统的最初灵感是智能手机扫描网站登录页面上的二维码，但对该模型的一个小补充实现了两种更重要的操作模式：只需将二维码图像也作为指向相同的可点击链接编码到二维码中的 URL。这产生了三种登录方式：

• 使用智能手机扫描代码：使用上述模型，用户的智能手机扫描出现在网站登录页面上的二维码，然后用户登录该网站。
• 在智能手机上点击代码：要在智能手机上登录网站，当可视 SQRL 代码也是 URL 样式的链接（使用 sqrl:// 作为方案）时，安装在智能手机中的 SQRL 应用程序将接收该链接并安全地将用户登录到手机上的站点。
• 单击台式机或笔记本电脑屏幕上的代码：要在任何台式机或笔记本电脑系统上使用 SQRL 系统，将安装一个桌面 SQRL 应用程序并将其自身注册以接收 sqrl:// 链接。（这类似于电子邮件程序注册接收 mailto: 链接的方式。）这允许用户在他们的桌面上使用他们在智能手机上使用的相同解决方案。当任何网站提供 SQRL 代码时，用户只需用鼠标单击代码，本地安装的 SQRL 应用程序就会弹出，提示输入 SQRL 密码，确认域，然后登录。

误解：SQRL 主密钥完全未加密且不受保护地存储在您的手机上

我不确定为什么有些人会做出这个假设，因为对我来说很明显情况并非如此。SQRL 主密钥的保护方式与保护密码数据库的方式大致相同：使用强主密码。除非您还拥有他们的主密码，否则窃取用户的手机不会自动让您访问他们的在线身份。有关密钥管理的更多详细信息，请参阅 SQRL 网站上的SQRL 客户端密钥管理页面。

误区：如果您的主密钥被盗，您将无法更改您的登录凭据

这也是错误的。SQRL 提供了一种内置方式，允许真正的帐户持有人在密钥泄露的情况下更新其登录凭据。此功能称为身份锁定：

“身份锁定”可防止身份更改并允许恢复：这也足够重要，值得拥有自己的详细描述页面：“身份锁定协议”（此页面底部链接块中的第 4 页。）一旦用户的身份已与 Web 服务器建立，SQRL 客户端无法更改该身份。这意味着，如果最坏的情况发生，并且使用了非常弱且容易被猜到的密码，或者用户的手机或桌面被黑客入侵以获取其身份主密钥和密码，任何恶意第三方都无法更改用户的在线身份将他们锁定在自己的在线帐户之外。此外，通过加载一个正常离线的“身份解锁密钥”，其身份的真正所有者可以退休并替换其丢失或被盗的在线身份，从本质上从任何攻击者手中夺回，使他们以前的身份无用。

似是而非：SQRL 比现有的身份验证解决方案更容易受到网络钓鱼的攻击

好的，所以这实际上是部分正确的。当通过扫描二维码使用 SQRL 时，对网络钓鱼的保护确实很少。除非用户仔细确保其浏览器 URL 栏中显示的网站与 SQRL 客户端应用程序显示的网站相同，否则他们可能正在为攻击者授权登录会话。这仍然比密码要好，在密码中，钓鱼者可以永久访问他们的帐户（以及他们在其他地方拥有的共享相同密码的任何其他帐户），直到他们更改密码，但不如其他集成的解决方案用户的浏览器，例如 U2F 密钥、WebAuthn、客户端证书和（在某些情况下）密码管理器。

但是，当您在登录的同一设备上使用 SQRL 客户端时，SQRL 确实有一些针对网络钓鱼的保护措施。这些保护措施在 SQRL 网站上的 SQRL如何阻止网络钓鱼攻击部分下进行了解释。还有可能将 SQRL 与浏览器集成（可能通过插件），以提供更强大的网络钓鱼攻击保护；与 WebAuthn 和客户端证书等解决方案相当。

总的来说，我认为 SQRL 与网络钓鱼保护的密码管理器大致相同。当安装在用户登录的同一设备上时，它有可能提供强大的网络钓鱼防护，但安装在不同的设备上时提供的保护最小。

与替代品比较

现在让我们将 SQRL 与现有的广泛使用的身份验证解决方案进行比较。

密码

SQRL 在许多方面都远远优于密码。设置后不仅使用起来更方便，因为用户不必担心为每个站点记住或重新输入多个不同的密码，而且它还可以防止密码重复使用、弱密码、键盘记录，并且在某种程度上，网络钓鱼。

SQRL 与密码相比的缺点是，对于网站运营商来说实施起来更加困难，没有被广泛使用，初始设置需要更多时间，需要一些努力才能转移到新设备，并且为所有人提供单点故障如果主密钥被盗，用户的帐户（尽管如果用户在每个站点上使用相同的密码，最后一点也是密码的情况）。

密码管理器

在许多方面，SQRL 与密码管理器非常相似。它们都提供了一个单一的、集中的信任锚，用作用户和单个服务之间的一种身份验证代理。尽管 SQRL 优于密码管理器，但有几种方法。

我认为 SQRL 与密码管理器相比的主要优势在于，在不受信任或仅部分受信任的计算机上使用它更容易、更安全。例如，假设用户想要使用公共图书馆的计算机登录网站。使用密码管理器，他必须要么在手机上访问该站点的密码，然后手动将其重新输入计算机，要么将他的密码管理器和密码数据库下载到图书馆计算机上，使用他的主密码解锁数据库，然后登录第一种情况对用户来说很不方便，并且会将用户在该站点的明文密码暴露给不受信任的计算机（以及不受信任计算机上的任何恶意软件，包括键盘记录器）。第二种情况更糟糕，因为它既不方便，又暴露了用户的全部，解密密码数据库和主密码到不受信任的计算机。使用 SQRL，用户只需在不受信任的计算机屏幕上扫描 QR 码，这对用户来说更加方便，并且只向不受信任的计算机公开一个登录会话（没有可重复使用的凭据，如密码）。

SQRL 相对于密码管理器的另一个优势是它更容易从最坏的情况中恢复：用户的密码数据库/主密钥被盗。使用密码管理器，您不仅需要在每个站点上更改密码，还必须担心攻击者会更改您的密码（可能会将您锁定在帐户之外）。攻击者还具有拥有您拥有帐户的所有站点列表的优势，从而使利用盗窃密码数据库变得更加容易。使用 SQRL，您的主密钥被盗仍然是一个可怕的情况，但攻击者没有您拥有帐户的网站列表（不得不猜测），并且无法更改您的密码以将您锁定在您的帐户之外。一旦你加载你的身份解锁密钥它' 在每个站点上更改您的登录凭据也更方便一些，因为 SQRL 客户端能够为您在登录时访问的每个站点自动为您执行此操作。（无需通过任何“更改密码”表格。）

最后，我认为 SQRL 在完全替换密码的目标方面比密码管理器有一个小而重要的优势，那就是网站可以选择强制使用 SQRL 而不是传统密码。只要用户仍然可以选择低安全性，在每个站点上重复使用相同的密码，这仍然会发生。如果 SQRL 开始获得广泛采用，网站实际上可以开始逐步淘汰密码的使用。密码管理器无法做到这一点，因为它们依赖于使用密码才能工作。

就缺点而言，我实际上想不出 SQRL 在安全性方面必然比密码管理器更差的情况。SQRL 的主要缺点是它需要网站运营商的支持，而密码管理器不需要现有服务的特殊支持。这意味着您现在可以开始使用密码管理器，但 SQRL 必须等到站点实施它才能使用。这是采用的一个重大障碍。

客户证书

SQRL 相对于客户端证书的主要优势之一是方便。客户端证书目前设置复杂，难以在计算机之间传输，并且在不同站点使用相同证书时存在隐私问题。虽然理论上我们可以使用客户端证书构建一个系统来解决这些问题，但也会存在与网站 UI 和 Web 服务器集成不佳的问题，这是更难以解决的问题。我不会在这里详细介绍，因为browserauth.net 上已经有一篇关于客户端证书可用性问题的优秀文章。

在安全性方面，客户端证书的缺点是需要 CA 的参与。这（可能）很昂贵，并且需要信任第三方 CA。此外，如果您选择忽略 CA 而是对您的证书进行自签名，则您需要处理证书吊销的问题。当用户想要在不受信任的计算机上登录时，客户端证书也具有与密码管理器相同的安全性和便利性问题；他们必须将他们的证书转移到不受信任的计算机上，这既不方便，又可能将他们的主身份暴露给该计算机上的恶意软件。

简而言之，在有人提出使用客户端证书来解决（至少大部分）这些问题的更好、用户友好的解决方案之前，我不认为客户端证书是 SQRL 的重要竞争对手（或者，就此而言，密码）。

2 因素身份验证

只是想我会提到这一点：SQRL 和 2 因素身份验证并不相互排斥。SQRL 替代了 2FA 中的第一个因素：密码。其他附加措施（如 OTP 代码或 FIDO U2F 密钥）仍可与 SQRL 一起使用。

网络认证

现在事情变得有趣了。WebAuthn是一个新的（嗯，比 SQRL 更新的）W3C 标准，旨在提供一个标准 API，网站可以使用 Web 上的公钥对用户进行身份验证。就像 SQRL 一样，它支持使用用户的手机对外部设备上的登录会话进行身份验证，此外还有一些其他身份验证方法（例如第二因素安全密钥）。

这就是 SQRL 最终遇到的地方，至少从安全角度来看是这样。WebAuthn 不仅提供与 SQRL 相同的针对密码重用、弱密码和键盘记录的所有保护，而且通过与用户的浏览器集成，即使在授权用户以前没有的 PC 登录会话时，它也提供更强大的网络钓鱼保护设置验证器的客户端软件。这是可能的，因为在这种情况下，WebAuthn 直接使用蓝牙或 NFC 等双向通信协议与用户的浏览器进行通信，而不是通过单向 QR 码与用户正在使用的网站进行通信。

从可用性的角度来看，事情要复杂一些。至少从表面上看，WebAuthn 再次获胜。因为它是 W3C 标准，已经在多个浏览器中实现，理论上用户可以立即开始使用 WebAuthn，而无需安装任何第三方软件。但在实践中，大多数现有的 WebAuthn 实现都专注于将其用作第二因素身份验证的一种形式，或者作为一种重新验证先前通过不同登录方法（通常是密码）在同一设备上登录的用户的方式。作为主要的身份验证因素，WebAuthn 仍然缺乏可行的实现。

其他次要考虑因素包括，SQRL 有一个内置方法可以在主密钥被盗的情况下轮换帐户密钥，而 WebAuthn 依赖于网站实现自己的系统来撤销密钥，以及 WebAuthn 需要某些可选硬件（如蓝牙或 NFC），以便对远程机器进行身份验证，而 SQRL 可以在任何具有工作显示器的机器上工作。

总的来说，我认为 WebAuthn 很可能最终会使 SQRL 过时。SQRL 目前可能还有一点喘息的空间，但 WebAuthn 得到了浏览器供应商、站点运营商和其他第三方组织（如 W3C）的强大支持。一旦 WebAuthn 获得了一些实现，使其能够用作主要的身份验证因素，我预计它将很快开始接管网络。

注意事项

SQRL 仍在积极开发中，因此此答案中提供的材料可能会发生变化。随着发展的继续，我希望这个答案中的一些漏洞和不确定性将得到解决。目前大部分讨论都在 grc.com 上的SQRL新闻组上进行。

SQRL 是解决用户名/密码悖论问题的便捷方法。（即便利性/安全性权衡）而不使用第三方. 它为最流行的身份验证模型（用户名和密码）提供了一个简单的替代方案，几乎不会影响安全性。只要您仍然有安全意识，它实际上与当今使用的任何常见身份验证模型一样安全。如果您使用的是 SQRL，这并不意味着您不能遵循最佳安全实践，例如将其与重要帐户的多因素身份验证相结合。

重要的是不要错过 SQRL 的要点。 SQRL 本身不需要提供更好或更差的安全性。如果计算机/手机本身受到攻击，或者用户被诱骗被钓鱼，那么这是一种旁道攻击，而不是 SQRL 本身的直接故障。 每种传统的身份验证方法都存在侧信道攻击 的问题。牢不可破的一次性密码本也容易受到侧信道攻击，例如密码本本身的危害，或者周围的安全性或实施不良。

如果您在 Steve Gibson 的播客上收听了该想法的原始提案，然后是问答，那么此堆栈线程上提出的许多问题都已得到解答。此外，史蒂夫自己说，这个非常“简单”和“巧妙”（他的话）的想法需要安全专家“审查”和“敲定”，因为只有时间才能证明这是否是一个安全的解决方案。

总之，大多数反对 SQRL 的论点都不属于 SQRL 本身的领域，而是与人类实践安全性差的问题有关。 SQRL 没有引入我们的传统身份验证方法已经没有的新问题分类。

如果有安全意识的人适当地使用 SQRL，它会非常出色。您必须了解，便利性和安全性之间总是存在权衡，而这种解决方案可能是我见过的两者的最佳平衡。

像往常一样，用一卡车盐带走任何与史蒂夫吉布森有关的东西。强制性 attrition.org链接。

让我们看看 Gibson 对他的协议的描述。

• 登录提示附近显示的 QR 码包含该站点的身份验证服务的 URL。该 URL 包含一个安全生成的长随机数，因此登录页面的每个演示文稿都会显示不同的 QR 码。（在加密圈子中，这个长随机数被称为“随机数”。）

• 智能手机的 SQRL 身份验证应用程序以加密方式对由用户主密钥加密的站点域名进行哈希处理，以生成特定于站点的公钥对。

• 该应用程序使用特定于站点的私钥对包含在 QR 码中的整个 URL 进行加密签名。由于 URL 包含一个安全的长随机数（随机数），因此该站点和 QR 码的签名是唯一的。

• 该应用程序向 QR 码的 URL 发出安全的 HTTPS POST 查询，这是该站点的身份验证服务。POST 提供特定于站点的公钥和 QR 码 URL 的匹配加密签名。

• 身份验证网站通过返回标准 HTTP“200 OK”（不包含其他内容）来接收并确认 POST 查询。SQRL 应用程序确认用户签名的 QR 码已成功提交。

• 身份验证站点的 URL 包含通过用户的智能手机从登录页面返回的 nonce。它还具有该 URL 的加密签名，以及用户特定于站点的公钥。它使用公钥来验证签名对 URL 是否有效。这确认了产生签名的用户使用了与公钥对应的私钥。验证签名后，身份验证站点通过其特定于站点的公钥识别现在经过身份验证的用户。

让我大吃一惊的是用户对“万能钥匙”的使用。如果我正确阅读协议，则该单一主密钥控制用户的整个在线身份......

据推测，这个主密钥存储在用户手机中的应用程序数据库中。这以专门用于窃取主密钥的恶意软件的形式打开了一个巨大的攻击向量。

因此，让我们比较一下密码泄露时发生的情况与主密钥泄露时发生的情况之间的区别。假设您遵循存储在密码管理器中的长、唯一和高度随机密码的良好密码实践，您所要做的就是在单个密码被泄露时更改它。如果您的主密钥被泄露怎么办？您将不得不以某种方式获取您通过身份验证的所有站点，以识别您的主密钥已被泄露。唯一的问题是，由于您没有任何其他方法可以向站点进行身份验证，例如用户名或电子邮件地址，站点如何知道实际上是您在尝试撤销主密钥？

与 Gibson 的任何产品一样，这种 SRQL 方案存在很大缺陷，与传统方法相比没有任何优势。