SQRLは間違っていなかった、ただ早すぎただけ
SQRL wan't wrong, it was early
パスキーが主流になるずっと前、Steve GibsonはSQRLというパスワードレス認証プロトコルを提案していた。著者は当時Wirehiveで働いており、SQRLの可能性に興奮し、実際にポータルに実装までした。しかし、SQRLは普及せず、10年後にパスキーが同じアイデアを実現した。この記事では、タイミングと業界全体の協調が技術の成功にどれほど重要かを振り返る。
私は間違っていなかったと思う。ただ、他の誰よりも10年早くそれを知っただけだ。
- paulryanrogers
SQRLにはパスキーと同じ弱点がある。デバイス上の秘密情報は簡単に失われすぎるし、ゲートキーパーはユーザーの主権を奪わずにそれを解決するには貪欲すぎる。そして人々はそれを理解していない。
私の意見では、両方の解決策は絶望的だ。私が単に皮肉屋で、何かがうまくいくことを願っているだけだといいのだが。
- kj4ips
DiscordとSteamには、SQRLが目指していたものと非常によく似たユーザーログインフローがあり、ユーザー名/パスワードフィールドと並んでQRコードも含まれている。これは別のシステムのクローズドな実装だが、使うたびにSQRLを思い出す。
偏っているかもしれないが、私はLinuxでPPP Pamモジュールを何年も使っていた。TOTPに移行するまでは、そして最終的に公開鍵のみに移行するまでは。
- breput
早すぎただけでなく、開発が長引いたのも問題だった。また、サーバーサイドの実装が適切になされることもなかったので、問題を探している解決策のように感じられたかもしれない。
とはいえ、その設計は、惨憺たる状況のパスキーよりもはるかに先進的であり、無制限のサイトサポートを簡単に実現できる小型のYubikeyタイプのデバイスにはるかに適している。また、本質的な移植性と、電子メールやSMSなどの弱い認証方法を無効にするようにサーバーに指示する証明書など、高度な現実世界のセキュリティ考慮事項も備えていた（これはカスタマーサポートの災害でもあるが、それでも...）。
結局のところ、SQRLは、最良の技術的設計が常に勝つとは限らないという教訓を示している。適切なタイミングと、堅牢なコミュニティ/企業のサポートが必要なのだ。
編集：また、（クライアントの）リファレンス実装はWindows用のx86アセンブリ言語で書かれていた。だから、タイミング、サポート、移植性のすべてが採用されなかった理由だと言える。