SQRL 没错，只是太早了
SQRL wan't wrong, it was early
每次看到 Passkeys 的普及，我都会想起 2013 年 Steve Gibson 在 Security Now! 节目中介绍 SQRL 的那个早晨。当时在 Wirehive 工作，我们正从 SSH keys 转向 SSH certificates，SQRL 提出的‘彻底抛弃密码’理念让我眼前一亮。它用非对称加密替代共享密钥，让钓鱼网站无利可图。我们甚至迅速为 Wirehive 门户添加了 SQRL 支持。可惜，SQRL 最终未能成为标准，因为它缺乏 Apple、Google、Microsoft 等巨头的协同支持。十年后，Passkeys 通过 FIDO Alliance 的标准和平台集成实现了同样的愿景。SQRL 并非失败，它只是在一个行业尚未准备好的时代，提前展示了无密码认证的未来。
我从未见过 FIDO Alliance 基于 Steve Gibson 工作的证据，我也不声称从 SQRL 到 WebAuthn 或 Passkeys 有直接联系。
- paulryanrogers
SQRL 和 passkeys 有同样的弱点：设备上的密钥太容易丢失，而守门人又太贪婪，不愿在不剥夺用户主权的前提下解决这个问题，而且大家根本不懂这玩意儿。
在我看来，这两个方案都没戏了。希望我只是太愤世嫉俗，说不定还能找到解决办法。
- breput
它确实太早了，但也在开发阶段拖得太久。而且它始终缺乏合适的服务端实现，所以给人的感觉像是在为不存在的問題寻找解决方案。
话虽如此，SQRL 的设计远比 Passkey 这个滚雪球式的灾难要先进得多，也更适合小型 Yubikey 类型的设备，在那里你可以轻松获得无限个网站的支持。它还具备内在的可移植性，以及更先进的现实安全考量，比如通过 attestations 指示服务器禁用较弱的认证方式（如邮箱或短信——这本身也是客服灾难，但即便如此……）。
归根结底，SQRL 是一个深刻的教训：最好的技术设计并不总能胜出——它需要恰当的时机，以及强大的社区和企业支持。
补充：另外，（客户端）参考实现是用 x86 汇编语言为 Windows 编写的。所以我认为，时机、支持和可移植性都是导致其未被广泛采用的原因。
- kj4ips
Discord 和 Steam 的用户登录流程与 SQRL 的目标非常相似，包括在用户名/密码字段旁边显示二维码。虽然这是另一个系统的封闭实现，但每次使用时我都会想到 SQRL。
我可能会有偏见，我在 Linux 上使用 PPP Pam 模块多年，后来转用 TOTP，最终过渡到仅使用公钥认证。