HN 日本語サマリー

← 一覧へ戻る
セキュリティ

SQRLは間違っていなかった、ただ早すぎただけ

SQRL wan't wrong, it was early (sjg.io)

14 pointsby simonjgreen2 コメント

要約

2013年頃に考案されたSQRL(Secure Quick Reliable Login)は、パスワードを完全に廃止し、ウェブサイトごとに異なる暗号学的IDを使用する革新的なログインシステムでした。しかし、ブラウザ、OS、ウェブサイト、ユーザーといった関係者全員の同時的な採用が必要だったため、普及には至りませんでした。10年後の現在、パスキーが同様のコンセプト(サービスごとの個別認証)で普及しつつあり、SQRLが時代を先取りしすぎていたことが証明された形です。

全文翻訳

時折、テクノロジーがいかにタイミングが重要であるかを思い出させてくれる技術に出くわします。パスキーもその一つです。Apple、Google、Microsoft、あるいはパスワードマネージャーベンダーが何か新しいものを発表するたびに、私の心は2013年か2014年頃の通勤中に戻ります。当時の多くの通勤中と同じように、私はSecurity Now!を聴いていました。Steve Gibsonが、Secure Quick Reliable Loginの略であるSQRLという、彼が開発していたものを紹介していました。その朝オフィスに到着し、その日の大半をそれについて話していたのを今でも覚えています。 私にとって、タイミングはこれ以上ないほど良かったのです。Wirehiveでは、SSHキーからSSH証明書への移行を進めており、認証とIDはほぼ毎日話題になっていました。スタックの一部で非対称暗号化が共有シークレットを置き換える方法についてすでに考えており、その時Steveは同じアイデアがウェブサイトへのログインにも応用できると説明しました。それはすぐに理解できました。パスワードマネージャーの追加や、パスワードをわずかにマシにするための別の試みよりも、はるかに興味深いものだと感じたことを覚えています。SQRLはより大きな問いを投げかけました。「もしパスワードを完全にやめたらどうなるだろうか?」あなたは、すべてのウェブサイトに対して異なる暗号学的IDを提示することになります。覚えるべき、あるいは再利用すべきパスワードはなく、盗まれるのを待つデータベース内の共有シークレットもありません。フィッシングサイトには、キャプチャする価値のあるものはほとんどなくなります。公開鍵暗号化がその役割を果たし、認証自体はほとんど見えなくなります。私はそれに夢中になりました。 その後まもなく、WirehiveポータルにSQRLサポートを追加するようにRobinを説得したと確信しています。当時はそのようなやり方でした。興味深いものを見つけたら、それを構築しました。委員会やステアリンググループ、あるいは6ヶ月のディスカバリー演習はありませんでした。誰かが数日間姿を消し、その後、それをサポートしたと何気なく言いました。振り返ってみると、それが懐かしいです。 しばらくの間、私はSQRLを密接に追跡し、認証がこの方向に向かうと期待していました。その後、あまり何も起こりませんでした。実装や熱心なコミュニティはありましたが、SQRLはそのコミュニティをはるかに超えて広がることはありませんでした。時間が経つにつれて、それについてあまり聞かなくなりました。 10年後、パスキーはオペレーティングシステム、ブラウザ、パスワードマネージャーに組み込まれています。銀行やエンタープライズIDプロバイダーもそれらを導入しています。パスワードレス認証は、セキュリティポッドキャストから、一般の人々が暗号化を理解する必要なしに使用できる製品へと移行しました。その進歩を見るたびに、私はSQRLが大人になった姿を思い浮かべます。 アーキテクチャは異なります。最新のパスキーは、各サービスに個別の認証情報を作成し、デバイス間で同期できます。SQRLは、マスターIDから各ウェブサイトのIDを決定論的に導き出しました。彼らは異なるエンジニアリング上の選択をしましたが、馴染みのある前提から出発しました。人々は、使用するすべてのサービスに対して共有シークレットを覚える必要があってはならない、という前提です。 FIDO AllianceがSteve Gibsonの業績に基づいて構築されたという証拠は見たことがなく、SQRLからWebAuthnやパスキーへの直接的なつながりを主張するつもりはありません。公開鍵認証はSQRLより前から存在しており、当時多くの優秀な人々がパスワードレス認証に取り組んでいました。Steveは、業界が広く展開する準備ができる何年も前に、パスワードレスWeb認証がどのように機能するかを具体的な技術的詳細で示した功績に値します。 SQRLの困難な問題は調整でした。プロトコルがいかにエレガントであっても、ブラウザ、オペレーティングシステム、ウェブサイト、ユーザーがすべて同時に動かなければ、通常のログイン方法になることはできませんでした。それは決して起こりませんでした。 パスキーは、異なるルートで同じ領域に到達しました。Apple、Google、Microsoftは共通の標準を支持し、それらをプラットフォームに統合しました。ブラウザはサポートを獲得し、パスワードマネージャーがそれに続き、ウェブサイトはユーザーに馴染みのない認証システムを探し出すよう説得することなくパスキーを導入できるようになりました。そのサポートこそが、SQRLが欠けていたものでした。公開鍵ログインは、人々がすでに使用していたソフトウェアがほぼ同時にサポートを開始したため、実用的になりました。 私たちは標準となったテクノロジーを記憶し、そのアイデアを早くから示した人々を忘れがちです。SQRLはWebの認証標準にはなりませんでしたが、最大のプラットフォームベンダーが提供する準備ができるずっと前に、パスワードレス認証がどのようなものになりうるかを示しました。 パスキーで何かをアンロックするたびに、私は今でもあの通勤中のドライブとWirehiveのオフィスに入り、このSQRLという奇妙なものが未来になるかもしれない理由を、聞く耳のある人に説明しようとしたことを思い出します。結果として、私は間違っていたとは思っていません。ただ、みんなより10年早く知っただけなのです。