SQRL 没错,只是太超前了。
SQRL wan't wrong, it was early

原始链接: https://sjg.io/writing/sqrl-wasnt-wrong-it-was-early/

作者回顾了无密码身份验证的演变,并将现代通行密钥(Passkeys)与史蒂夫·吉布森(Steve Gibson)十多年前推出的 SQRL(安全、快速、可靠的登录)协议进行了对比。 早在 2013 年,作者就是 SQRL 的早期采用者,他意识到利用公钥加密技术取代共享密码是安全领域的未来。尽管作者和他在 Wirehive 的团队曾进行过实验性部署,但 SQRL 却难以实现主流化。其主要障碍在于协调性:它缺乏浏览器、操作系统和大型科技平台所需的广泛支持,难以推动行业变革。 如今,通行密钥在 SQRL 未能成功的地方取得了成功,这在很大程度上是因为苹果、谷歌和微软等行业巨头将该技术集成到了人们现有的工具中。虽然两者之间没有直接联系,但作者认为通行密钥是“成熟后的 SQRL”。归根结底,这篇文章是对那些往往先于其实际市场成功出现的远见卓识的致敬。它强调,虽然时机和平台集成是实现广泛采用的关键,但像吉布森这样的早期先驱者理应获得认可,因为他们在行业准备好实施之前就早已发现了解决方案。

``` Hacker News 最新 | 往期 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 SQRL 并没有错,它只是超前了 (sjg.io) 10 分,由 simonjgreen 发布于 2 小时前 | 隐藏 | 往期 | 收藏 | 2 条评论 帮助 kj4ips 31 分钟前 | 下一条 [–] Discord 和 Steam 的用户登录流程与 SQRL 的目标非常相似,包括在用户名/密码字段旁显示二维码。虽然这是另一个系统的闭源实现,但每次使用时我都会想到 SQRL。我可能有偏见,我曾在 Linux 上使用了多年的 PPP Pam 模块,直到后来转向 TOTP,最终改为仅使用公钥验证。 回复 DANmode 13 分钟前 | 上一条 [–] 呃,这很酷,但与 SQRL 诞生时就已经存在的 FIDO 相比,它显然是“错”的。 回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索: ```
相关文章

原文

Every so often I come across a piece of technology that reminds me just how much timing matters. Passkeys are one of those. Whenever Apple, Google, Microsoft or a password manager vendor announces something new, my mind goes back to a drive to work somewhere around 2013 or 2014.

Like many of my commutes back then, I had Security Now! playing. Steve Gibson was introducing something he’d been working on called SQRL, short for Secure Quick Reliable Login. I can still remember arriving at the office that morning and talking about it for most of the day.

The timing couldn’t have been better for me. At Wirehive we’d been moving from SSH keys to SSH certificates, so authentication and identity came up almost daily. We were already thinking about how asymmetric cryptography could replace shared secrets in one part of the stack, and then Steve described how the same idea might work for logging into websites.

It clicked immediately. I remember thinking that this was far more interesting than another password manager or another attempt to make passwords slightly less terrible. SQRL asked a bigger question: “What if we just stopped using passwords altogether?”

You would present a different cryptographic identity to every website. There would be no password to remember or reuse, and no shared secret sitting in a database waiting to be stolen. A phishing site would have very little of value to capture. Public key cryptography did the work while the authentication itself almost disappeared from view.

I loved it.

I am fairly sure I convinced Robin to add SQRL support to the Wirehive portal not long afterwards. That was how we operated back then. If we found something interesting, we’d build it. There wasn’t a committee, a steering group or a six-month discovery exercise. Someone would disappear for a couple of days and then casually mention they’d added support for it.

Looking back, I miss that.

For a while I followed SQRL closely and expected this to be where authentication was heading.

Then not much happened.

There were implementations and a committed community, but SQRL never escaped far beyond that community. Over time I stopped hearing much about it.

A decade later, passkeys are built into operating systems, browsers and password managers. Banks and enterprise identity providers are adopting them. Passwordless authentication has moved from security podcasts into products that ordinary people use without needing to understand the cryptography underneath.

Whenever I see that progress, I think of SQRL all grown up.

The architectures are different. Modern passkeys create separate credentials for each service and can synchronise them between devices. SQRL derived each website identity deterministically from a master identity. They made different engineering choices, but started from a familiar premise: people should not have to remember a shared secret for every service they use.

I have never seen evidence that the FIDO Alliance built on Steve Gibson’s work, and I am not claiming a direct line from SQRL to WebAuthn or passkeys. Public key authentication predates SQRL, and plenty of clever people were working on passwordless authentication at the time.

Steve still deserves credit for showing, in concrete technical detail, how passwordless web authentication could work years before the industry was ready to deploy it widely.

SQRL’s difficult problem was coordination. However elegant the protocol, browsers, operating systems, websites and users all needed to move together before it could become a normal way to log in. That never happened.

Passkeys reached the same territory by a different route. Apple, Google and Microsoft backed common standards and integrated them into their platforms. Browsers gained support, password managers followed, and websites could adopt passkeys without first persuading users to seek out an unfamiliar authentication system.

That support is what SQRL lacked. Public key login became practical because the software people already used began supporting it at roughly the same time.

We tend to remember the technology that became standard and forget the people who demonstrated the idea earlier. SQRL did not become the authentication standard for the web, but it showed what passwordless authentication could look like long before the largest platform vendors were ready to deliver it.

Every time I unlock something with a passkey, I still think back to that drive to work and walking into the Wirehive office, trying to explain to anyone who would listen why this strange thing called SQRL might just be the future.

As it turns out, I don’t think I was wrong. I just heard about it ten years before everyone else did.

联系我们 contact @ memedata.com