SQRLは、彼らが言うほど本当に安全ですか？
私は出会ったばかり https://www.grc.com/sqrl/sqrl.htm
セキュアQRログインを使用すると、携帯電話はウェブサイトのログインページに表示されるQRコードをスナップします。 。 。 。そしてあなたは安全にログインしています。
これはかなり素晴らしいようです-私が考えることができる問題の1つは、QRリーダーが危険にさらされている場合、www.google.comではなくwww.nsa-super-secret-place.gov/123を表示することです。このシステムには他にどのような問題がありますか？
いつものように、トラックの荷を積んだスティーブギブソンに関連するものなら何でも持ちます。必須attrition.org リンク 。
ギブソンの彼のプロトコルの説明を見てみましょう。
ログインプロンプトの近くに表示されるQRコードには、サイトの認証サービスのURLが含まれています。 URLには安全に生成された長い乱数が含まれているため、ログインページのすべての表示に異なるQRコードが表示されます。 （クリプトサークルでは、この長い乱数は「ナンス」と呼ばれます。）
スマートフォンのSQRL認証アプリは、ユーザーのマスターキーによってキーが設定されたサイトのドメイン名を暗号化してハッシュし、サイト固有の公開キーペアを生成します。
アプリは、サイト固有の秘密鍵を使用して、QRコードに含まれるURL全体を暗号で署名します。 URLには安全な長い乱数（nonce）が含まれているため、署名はそのサイトとQRコードに対して一意です。
アプリは安全なHTTPS POSTクエリをサイトの認証サービスであるQRコードのURLに発行します。POSTはサイト固有の公開鍵を提供しますそしてQRコードのURLの一致する暗号署名。
認証Webサイトは、POSTクエリを受信して、他のコンテンツなしで標準のHTTP "200 OK"を返すことで確認します。SQRLアプリは、ユーザーが署名したQRコードの送信が成功したことを確認します。
認証サイトには、ユーザーのスマートフォンを介してログインページから戻ってきたnonceを含むURLがあります。また、そのURLの暗号署名とユーザーのサイト固有の公開鍵も含まれています。公開鍵を使用して、署名がURLに対して有効であることを確認します。これにより、署名を作成したユーザーが公開鍵に対応する秘密鍵を使用したことが確認されます。署名を検証した後、認証サイトは、現在認証されているユーザーをサイト固有の公開鍵で認識します。
私が飛び出る最大のことは、ユーザーによる「マスターキー」の使用です。プロトコルを正しく読んでいる場合、その単一のマスターキーがユーザーのオンラインID全体を制御します...
おそらく、このマスターキーはユーザーの電話のアプリケーションデータベースに格納されています。これにより、マスターキーを盗むために特別に設計されたマルウェアの形で巨大なギャップ攻撃ベクトルが開かれます。
それでは、パスワードが侵害された場合とマスターキーが侵害された場合の違いを比較してみましょう。パスワードマネージャーに保存された、長くてユニークで非常にランダムなパスワードの適切なパスワードプラクティスに従っているとすると、パスワードが危険にさらされた場合に1つのパスワードを変更するだけで済みます。マスターキーが不正使用された場合はどうなりますか？マスターキーが危険にさらされていることを認識するには、認証に使用したサイトallを何らかの方法で取得する必要があります。唯一の問題は、ユーザー名や電子メールアドレスなど、サイトで認証する他の手段がないため、マスターキーを取り消そうとしているのが実際にあなたであることをサイトはどのように知るのでしょうか。
ギブソンから出てくるものと同じように、このSRQLスキームには非常に欠陥があり、従来の方法に比べて利点はありません。
全体として、このプロトコルは既存のテクノロジーよりもセキュリティを向上させるようには見えません。オンラインでIDを保護するための最良の方法を探している場合、これは間違いなくそれではありません。しかし、長所と短所を見てみましょう：
メリット
悪意のあるWebサイトが、あるサイトに提供されている認証を使用して別のサイトにログインできないという狭い意味でパスワードを「共有」することは不可能です。
認証トークンに対するブルートフォース攻撃は実行できません。
資格情報はコンピューターに保存されません。これにより、ワークステーション向けの小さなサブセットの攻撃から保護されます。具体的には、コンピューターからパスワードを盗む攻撃から保護されます。あなたは保護されていませんあらゆる種類のセッションハイジャックまたはブラウザー乗っ取り攻撃から保護されていますが、今は電話の影響を受けやすい関連の攻撃。詳細は後ほど。
短所
この手法はMITM攻撃やソーシャルエンジニアリングの影響を受けやすくなっています。使用中の他の認証スキーム（パスワードを含む）よりも恐らくそうです。認証手順とログイン開始手順は、ユーザーに提示される方法や場所に関係なく、提示されたQRコードに対して電話が正しく認証されるという意味で本質的に切り離されています。
したがって、たとえば、フィッシングサイトは、ユーザーの代わりに攻撃者にログインする本物のログインQRコードを表示できます。ギブソン氏は、認証中にユーザーが電話アプリで銀行、店舗、またはサイトの名前を確認できるため、攻撃を阻止するために十分な警戒を怠らないと確信しています。履歴ではこれはありそうもないことを示唆しており、アプリで正しい名前を見ると、ユーザーが電話でおなじみのログインリクエストをトリガーできたため、サイトが正当であると誤解することをユーザーに安心させることがより合理的な期待です。パスワードセキュリティに関するユーザーの頭にすでにある警告は、必ずしもこのような新しい認証技術につながるとは限りません。そのため、このアプリはソーシャルエンジニアリングへの耐性が本質的に低くなります。
この手法は、認証とIDの両方を、頻繁に紛失または盗難される物理オブジェクトに結合します。このこれは、パスワードではなくパスポートのようなものです。あなたの電話を所持している誰もが突然あなたの身元を独占して：攻撃者があなたになりすますことができるだけでなく、2番目の電話に2番目のコピーがなければ（そうではない）、今はあなたあなた自身を識別する能力を失った。認証キーは取り消すことができないため、すべてのサイトから帯域外の回復がないと、IDを回復できません。また、帯域外リカバリが存在する場合でも、IDを所有しているユーザーとIDを所有していないユーザーの2人に直面すると、サイトオペレーターがあなたを信頼する理由がわかりにくい場合があります。
この手法では、手動で他のトークンを作成しない限り、すべての認証トークンを1つのキーに結合します。これにより、1つのキーが攻撃者にとって非常にジューシーなターゲットになります。さらに、キーはお使いの携帯電話に保存されますが、これらのデバイスは通常、笑えるほど多孔質な内部セキュリティを備えています。異常にジューシーなターゲットと標準以下のセキュリティを組み合わせても、安全ではありません。
代替案
このスキームの最も問題のある側面は、利用可能な代替案と比較してどれだけ劣るかです。
今日、最も安全で普遍的に受け入れられているオプションは、lastpass、keepass、およびその他のそのようなブラウザー統合パスワードシステムです。特に、クライアント側の暗号化により、第三者を信頼する必要性が軽減されます。さらに重要なことに、ブラウザの統合により、フィッシングが事実上不可能になります。 LastPassまたはKeePassは、正しいドメインから提供された場合にのみパスワードを入力します。つまり、悪意のあるサイトが提示された場合、ユーザーは自分のパスワードにアクセスできません。
さらに、LastPassは最近、グローバルに一意ではないパスワードの変更をユーザーに強制する機能を追加しました。これにより、パスワードの再利用を防ぐことができます。つまり、Gibsonの手法の主要な利点は、現在のサイトでこのツールを使用すると、彼のスキームが意味する追加の不安を伴うことなく簡単に得ることができます。
電話または類似のデバイスを使用する既存の第2要素認証スキームは、デバイスが盗まれてもIDの盗難に対してすぐに脆弱にならないような方法で、今日すでにユーザーログインを保護するのに役立ちます。 2要素認証のセキュリティが強化されているのは、デバイスもパスワードも、他のデバイスなしで盗まれた場合には使用できないという事実にあります。ギブソンの技術は、このレベルの保護を利用できないようにする2要素スキームに含まれることに大きく抵抗しています。
TL; DR：
ギブソンの認証技術は、それが課す追加のセキュリティコストを克服するのに十分な利点を生み出しません。これらのコストはスキーム自体の基本的な部分であり、デザイン全体を廃棄せずに解決することはできません。
何もないよりはましだと主張することはできますが、すでに持っているものよりもましだと主張することはできません。
ギブソンのアップデート
ギブソンは最近、これが主要な批判であるので、フィッシングに対するいくつかの追加の保護を発表しました。その保護は次のとおりです。QRコードや携帯電話などを使用せず、代わりにシステムに認証エージェント（ブラウザ内など）がある場合、サーバーは認証を確認して応答は、認証要求と同じIPから送信されます。これは良いことですが、このプロトコルの目的はすべて、身元を携帯電話に移すことです。プロトコルを使用する唯一の安全な方法が、そのコア機能を使用しないことである場合、おそらく、達成しようとしていることを再考する必要があります。
理論的には、あなたの携帯電話があなたのコンピュータと同じIPを使用していることを知っていた場合（かつその場合のみ）、あなたはあなたの携帯電話を使い続けることができます。もちろん、コンピュータのIPアドレスがわからないため、これはわかりません。
より良いソリューション
前述のように、認証手段がブラウザーにある場合は、ユーザー側の努力や検証なしに、フィッシングの問題全体が即座に解決されます。サイトの認証トークンはドメイン名に関連付けられており、ブラウザは間違ったドメインへの認証を許可しないため、最も能力の低いユーザーでもだまされて間違ったサイトに認証されることはありません。これは現在すでに使用されている手法であり、完全に自動化されており、サイトの協力やユーザー側のインテリジェンスを必要としません。
この方法は、2番目の認証要素（携帯電話の時変キーなど）を要求することで強化できます。これは、現在も利用可能であり、今日使用されており、パーツのねじ込みから（特に）保護します。宛先サイトまたは会社の。
ブラウザー側の認証がクライアントワークステーション攻撃に対して脆弱であるという懸念に関しては、trueである一方で、ブラウザーが危険にさらされている場合、そのブラウザーの使用は安全ではありません、使用する認証メカニズムに関係なく。マルウェアの作成者は、スーパーセキュアテクニックを使用して自分で認証するのを待って（そしてすでにそうしている）、その後、必要なトラフィックを静かに送信してアカウントを「所有する」ことができます。 SQRLも他の認証システムも、侵害されたブラウザのユーザーを保護することはできません。ドアロックが家の火災からあなたを保護することはできます。耐火ロックを購入することは解決策ではありません。
次の場所
偽装からの保護の絶対的な保証 を探している場合は、Fido U2Fトークンを確認してください。この標準は、SQRLが不十分な場合に最適であり、MITM（フィッシングなど）攻撃に対する耐性を保証します。これは、ユーザーだけでなくチャネルも認証することによって行われるため、（a）トークンなしではアカウントを認証できないこと、および（b）トークンは接続の認証にのみ使用できることが保証されます接続されているマシンに詳細は this answer を参照してください。
SQRLには欠陥がないわけではありませんが、セキュリティと（そしてこれは重要です）使いやすさの点で今日Webで広く使用されているほとんどの主要認証ソリューションよりも確かに優れています。説明させてください。
誤解
まず、この質問の他の回答のいくつかにある誤解のいくつかを整理しましょう。これらの回答の多くは古く、SQRLのドキュメントに変更が加えられる前に記述されており、それらの問題に対処していますが、広く使用されている他の多くの既存の認証ソリューションにも存在するSQRLの欠陥に過度に重点を置いているようです。その利点を無視します。では、ここでいくつかの誤解を解消しましょう。
神話：SQRLが機能するにはQRコードをスキャンする必要がある
これは単に真実ではありません。 QRコードは、ユーザーがSQRLクライアントソフトウェアをセットアップしていないコンピューターでSQRLを使いやすくするための便利なものです。 SQRLのWebサイトには、次のように記載されています。
行く3つの方法。 。 。オプションのスマートフォン：
このシステムの開発の最初のインスピレーションは、ウェブサイトのログインページでQRコードをスキャンするスマートフォンでしたが、そのモデルに少し追加するだけで、さらに2つの重要な操作モードが可能になります。QRコード画像を同じものにクリック可能なリンクにするだけですQRコードにエンコードされたURL。これにより、3つのログイン方法が得られます。
- スマートフォンでコードをスキャンします：上記のモデルを使用して、ユーザーのスマートフォンがWebサイトのログインページに表示されるQRコードをスキャンし、ユーザーがログインしますそのサイト。
- スマートフォンでコードをタップします：ビジュアルSQRLコードがURLスタイルのリンクでもある場合、スマートフォンでWebサイトにログインするには（sqrlを使用： //スキームとして）スマートフォンにインストールされたSQRLアプリがそのリンクを受信し、ユーザーを電話のサイトに安全にログインさせます。
- デスクトップまたはラップトップの画面でコードをクリックします：デスクトップまたはラップトップシステムでSQRLシステムを使用するには、デスクトップSQRLアプリケーションをインストールして登録しますそれ自体がsqrl：//リンクを受信します。 （これは、メールプログラムがmailto：リンクを受信するために登録する方法に似ています。）これにより、ユーザーはスマートフォンで使用しているのと同じソリューションをデスクトップ上のユーザーが使用できます。 WebサイトがSQRLコードを提供する場合、ユーザーはマウスカーソルでコードをクリックするだけで、ローカルにインストールされたSQRLアプリがポップアップし、SQRLパスワードの入力を求め、ドメインを確認して、ログインします。
神話：SQRLマスターキーは完全に暗号化されず、保護されずに携帯電話に保存されます
なぜこれが当てはまらないのか私には明らかなように、なぜ一部の人々がこの仮定をしたのかはわかりません。 SQRLマスターキーは、パスワードデータベースを保護するのとほぼ同じ方法で、強力なマスターパスワードを使用して保護されます。ユーザーの電話番号を盗んでも、マスターパスワードがなければ、オンラインIDに自動的にアクセスすることはできません。キー管理の詳細については、SQRLのWebサイトの SQRLクライアント側キー管理 のページで説明されています。
神話：マスターキーが盗まれた場合、ログイン資格情報を変更できない
これも誤りです。 SQRLには、正規のアカウント所有者がキーが危険にさらされた場合にログイン資格情報を更新できるようにする組み込みの方法が用意されています。この機能はIDロックと呼ばれます。
「IDロック」はIDの変更を防ぎ、回復を許可します：これは、独自の詳細説明ページに値するほど重要です：「 IDロックprotocol ”（このページの下部にあるリンクブロックの4ページ。）ユーザーのIDがWebサーバーで確立されると、SQRLクライアントはunableそのアイデンティティを変更します。つまり、最悪の事態が発生し、非常に脆弱で簡単に推測できるパスワードが使用された場合、またはユーザーの電話またはデスクトップがハッキングされてIDマスターキーとパスワードを取得した場合、悪意のある第三者はユーザーのオンラインIDを変更して、ユーザーを自分のオンラインアカウントからロックアウトします。さらに、通常はオフラインの「IDロック解除キー」をロードすることにより、IDの真の所有者は、紛失または盗難されたオンラインIDを撤回して交換し、本質的にそれを取り戻すことができます攻撃者からの攻撃で、以前のIDが役に立たなくなります。
もっともらしい：SQRLは既存の認証ソリューションよりもフィッシングに対して脆弱です
さて、これは実際には部分的にtrueです。 QRコードをスキャンしてSQRLを使用する場合、実際にはフィッシングに対する保護はほとんどありません。ユーザーがブラウザーのURLバーに表示されるWebサイトがSQRLクライアントアプリによって表示されるWebサイトと同じであることを確認するように注意していない限り、攻撃者のログインセッションを許可している可能性があります。これはパスワードよりも優れており、パスワードを変更するまで、フィッシャーは自分のアカウント（および他の場所で同じパスワードを共有している他のアカウント）に永続的にアクセスできますが、と統合する他のソリューションほど優れていませんU2Fキー、WebAuthn、クライアント証明書、および（特定の条件下では）パスワードマネージャーなどのユーザーのブラウザー。
ただし、ログインに使用しているのと同じデバイスでSQRLクライアントを使用している場合、SQRLはフィッシングに対する保護を備えています。これらの保護については、SQRLのWebサイトの SQRLがフィッシング攻撃を阻止する方法 のセクションで説明しています。また、SQRLをブラウザーと（おそらくプラグインを介して）統合して、フィッシング攻撃に対するはるかに強力な保護を提供する可能性もあります。 WebAuthnやクライアント証明書などのソリューションと同等です。
全体として、フィッシング保護のために、SQRLをパスワードマネージャーとほぼ同じレベルにランク付けします。ユーザーがログインしているのと同じデバイスにインストールすると、フィッシングに対する強力な保護を提供する可能性がありますが、別のデバイスにインストールすると、最小限の保護を提供します。
代替案との比較
次に、SQRLを既存の広く使用されている認証ソリューションと比較してみましょう。
パスワード
SQRLは、多くの点でパスワードよりもはるかに優れています。ユーザーはサイトごとに複数の異なるパスワードを覚えたり再入力したりする必要がないので、一度設定すると使いやすいだけでなく、パスワードの再利用、脆弱なパスワード、キーロギング、およびある程度、から保護されます。フィッシング。
SQRLがパスワードと比較した短所は、広く使用されていないため、Webサイトオペレーターに実装するのがより困難であり、初期設定に時間がかかり、新しいデバイスに転送するために多少の労力が必要であり、すべてに単一障害点を提供することですマスターキーが盗まれた場合のユーザーのアカウント（この最後の点は、ユーザーがすべてのサイトで同じパスワードを使用する場合のパスワードの場合も同様です）。
パスワードマネージャー
多くの点で、SQRLはパスワードマネージャーによく似ています。どちらも、ユーザーと個々のサービス間の一種の認証プロキシとして機能する単一の集中トラストアンカーを提供します。ただし、SQRLがパスワードマネージャよりも優れている方法は2つあります。
SQRLがパスワードマネージャよりも優れていると思う主な利点は、信頼されていない、または部分的にのみ信頼されているコンピュータで使用する方が簡単で安全であることです。たとえば、ユーザーが公共図書館のコンピューターを使用してWebサイトにログインしたいとします。パスワードマネージャーを使用すると、電話でそのサイトのパスワードにアクセスして手動でコンピューターに再入力するか、パスワードマネージャーとパスワードデータベースをライブラリコンピューターにダウンロードし、マスターパスワードを使用してデータベースのロックを解除して、ログに記録する必要があります。最初のシナリオはユーザーにとって不便であり、その1つのサイトのユーザーのプレーンテキストパスワードを信頼できないコンピューター（およびキーロガーを含む、信頼できないコンピューター上のマルウェア）に公開します。 2番目のシナリオは、どちらも不便であり、ユーザーの暗号化されたパスワードデータベース全体とマスターパスワードを信頼できないコンピューターに公開するため、さらに悪い状況です。 SQRLを使用すると、ユーザーは信頼されていないコンピューターの画面でQRコードをスキャンするだけで済み、ユーザーにとって非常に便利であり、信頼されていないコンピューターに単一のログインセッション（パスワードなどの再利用可能な資格情報なし）を公開するだけです。
SQRLがパスワードマネージャーよりも優れているもう1つの利点は、ユーザーのパスワードデータベース/マスターキーが盗まれたという最悪のシナリオからの回復が簡単なことです。パスワードマネージャーを使用すると、すべてのサイトでパスワードを変更する必要があるだけでなく、攻撃者がパスワードを変更する（アカウントからロックアウトされる可能性がある）ことについても心配する必要があります。攻撃者には、アカウントを持っているすべてのサイトのリストを所持できるという利点もあります。これにより、パスワードデータベースの盗難がはるかに簡単になります。 SQRLを使用しても、マスターキーが盗まれるのは依然として恐ろしい状況ですが、攻撃者はアカウントを持っている（代わりに推測する必要がある）サイトのリストがなく、パスワードを変更してアカウントからロックアウトすることはできません。 IDロック解除キーをロードすると、SQRLクライアントがログイン時にアクセスする各サイトに対して自動的にそれを実行する機能を備えているため、各サイトのログイン資格情報を変更することも少し便利です。 （「パスワードの変更」フォームを通過する必要はありません。）
最後に、SQRLには、パスワードを完全に置き換えるという目的に関して、パスワードマネージャーよりも小さいが重要な利点が1つあると思います。つまり、サイトには、従来のパスワードよりもSQRLの使用を強制するオプションがあります。ユーザーが依然としてセキュリティが低いという選択肢がある限り、すべてのサイトで同じパスワードを再利用しますが、それはまだ起こります。 SQRLが広く採用され始めた場合、サイトは実際にはパスワードの使用を段階的に廃止することができます。パスワードマネージャーは機能するためにパスワードの使用に依存しているため、これを行うことはできません。
欠点については、セキュリティの点でSQRLが必ずしもパスワードマネージャーよりも劣る状況を考えることはできません。 SQRLの主な欠点は、Webサイトオペレーターからのサポートが必要なのに対し、パスワードマネージャーは既存のサービスからの特別なサポートを必要としないことです。これは、今すぐパスワードマネージャーの使用を開始できることを意味しますが、SQRLを使用するには、サイトがそれを実装するまで待機する必要があります。これは採用の大きな障壁です。
クライアント証明書
SQRLがクライアント証明書よりも優れている主な利点は、利便性の1つです。クライアント証明書は現在、設定が複雑で、コンピューター間での転送が困難であり、同じ証明書を異なるサイトで使用するとプライバシーの問題が発生します。理論的には、これらの問題を解決するクライアント証明書を使用してシステムを構築することもできますが、WebサイトのUIやWebサーバーとの統合が不十分であるという問題もあります。 browserauth.netのクライアント証明書の使いやすさの問題について 優れた記事 がすでにあるので、ここではあまり詳しく説明しません。
セキュリティの面では、クライアント証明書にはCAの関与を必要とするという欠点があります。これは（潜在的に）費用がかかり、サードパーティのCAを信頼する必要があります。さらに、CAを無視し、代わりに証明書に自己署名することを選択した場合、処理する証明書の失効の問題が発生します。クライアント証明書には、ユーザーが信頼できないコンピューターにログインする場合のパスワードマネージャーと同じセキュリティと利便性の問題もあります。彼らは証明書を信頼できないコンピューターに転送する必要があります。これは不便であり、マスターIDをそのコンピューター上のマルウェアに公開する可能性があります。
要するに、誰かがこれらの問題を（少なくともほとんど）解決するクライアント証明書を使用するより優れたユーザーフレンドリーなソリューションを思い付くまで、クライアント証明書がSQRLとの重大な競合相手であるとは思いません（または、さらに言えば、パスワード）。
2要素認証
私がこれに言及したと思っただけです：SQRLと2要素認証は相互に排他的ではありません。 SQRLは、2FAの最初の要素であるパスワードに置き換わるものです。 OTPコードやFIDO U2Fキーなどの他の追加の手段は、SQRLで引き続き使用できます。
WebAuthn
さて、ここが面白いところです。 WebAuthn は新しい（まあ、SQRLよりも新しい）W3C標準であり、Web上の公開鍵でユーザーを認証するためにWebサイトが使用できる標準APIを提供するように設計されています。 SQRLと同様に、他のいくつかの認証方法（第2要素のセキュリティキーなど）に加えて、 ユーザーの電話を使用して外部デバイスのログインセッションを認証する をサポートしています。
これは、少なくともセキュリティの観点から、SQRLが最終的に一致する場所です。 WebAuthnは、SQRLが行うパスワードの再利用、脆弱なパスワード、およびキーロギングに対する保護をすべて提供するだけでなく、ユーザーのブラウザーと統合することで、フィッシングに対するさらに強力な保護を提供しますevenユーザーが以前に認証システムのクライアントソフトウェアをセットアップしていないPCのログインセッションを承認する。これが可能なのは、その状況でWebAuthnがBlutoothまたはNFCのような双方向通信プロトコルを使用してユーザーのブラウザーと直接通信する代わりに、ユーザーが一方向QRコードを介して使用しているWebサイトと通信するためです。
ユーザビリティの観点からは、物事はもう少し複雑です。少なくとも表面上は、WebAuthnが再び勝利します。 すでに複数のブラウザに実装されている であるW3C標準であるため、理論上、ユーザーはサードパーティのソフトウェアをインストールする必要なく、すぐにWebAuthnの使用を開始できます。ただし実際には、ほとんどの既存のWebAuthn実装は、第2要素認証の形式として、または以前に別のログイン方法（通常はパスワード）を使用して同じデバイスにサインインしたユーザーを再認証する方法としての使用に重点を置いています。主要な認証要素として、WebAuthnは実行可能な実装にまだ欠けています。
その他のマイナーな考慮事項として、SQRLには、マスターキーが盗まれた場合にアカウントのキーをローテーションするための組み込みメソッドがあるという事実と、WebAuthnがWebサイトに依存してキーを取り消すための独自のシステムを実装していること、およびWebAuthnが特定のリモートマシンに対して認証するためのオプションのハードウェア（BluetoothやNFCなど）。SQRLは、ディスプレイが機能している任意のマシンで機能します。
全体として、WebAuthnが最終的にSQRLを廃止する可能性は非常に高いと思います。 SQRLには今のところ少し余裕があるかもしれませんが、WebAuthnはブラウザーベンダー、サイトオペレーター、およびその他のサードパーティ組織（W3Cなど）からの強力な支援を得ています。 WebAuthnが主要な認証要素としての使用を可能にするいくつかの実装を取得すると、Webをすぐに引き継ぐようになると思います。
注意事項
SQRLは現在も活発に開発されているため、この回答で示される内容は変更される可能性があります。開発が進むにつれて、この回答の脆弱性と不確実性のいくつかに対処することが期待されます。議論のほとんどは現在grc.comの SQRL newsgroup で行われています。
SQRLは、ユーザー名/パスワードのパラドックスの問題に対する便利なソリューションです（つまり、利便性とセキュリティのトレードオフ）。サードパーティを使用せずに。これは、最も一般的な認証モデル（ユーザー名とパスワード）の簡単な代替手段を提供し、セキュリティに妥協することなく事実上です。 実用的です今日使用されている一般的な認証モデルのどれかと同じくらい安全ですあなたがまだセキュリティを意識している限り。 SQRLを使用している場合でも、重要なアカウントのこれを多要素認証と組み合わせることなど、セキュリティのベストプラクティスに従うことができないという意味ではありません。
SQRLの要点を見逃さないことが重要です。 SQRL自体は必ずしもより良いまたはより悪いセキュリティを提供する必要はありません。コンピューター/電話自体が危険にさらされた場合、またはユーザーがフィッシングに騙された場合、これはSQRL自体の直接的な障害ではなく、サイドチャネル攻撃。 すべての従来の認証方法には、サイドチャネル攻撃のこの問題があります壊れないワンタイムパッドは、セキュリティ侵害などのサイドチャネル攻撃に対しても脆弱です。パッド自体、または周辺のセキュリティまたは実装の不良。
Steve Gibsonの podcast でアイデアの最初の提案を聞いた後、Q＆Aを聞いた場合、このスタックスレッドで提起された懸念の多くは解決されています。また、スティーブは、この非常に「単純」で「独創的」な（彼の言葉）アイデアは、セキュリティの専門家が「吟味」し、「叩き落とす」必要があると述べた。
結論として、SQRLに対する議論のほとんどはSQRL自体のドメインの範囲外であり、代わりに不十分なセキュリティを実践している人間の問題です。 SQRLでは、従来の認証方法にはない問題の新しい分類が導入されていません。
SQRLは、セキュリティを重視する人が適切に使用すれば優れています。 利便性とセキュリティの間には常にトレードオフがあることを理解する必要があります、この解決策はおそらく最適です私が見た2つのバランス。
他のコメントにはある程度同意しますが、いくつかのメリットがあると思います。
SQRLを有効にするには、マスターキーを作成して電話に保存する必要があります。できました。その秒から、「SQRL」を使用するすべてのWebサイトにログインできるようになります。そしてそれは匿名のログインになります-あなたがそれ以上の情報を提供しないことを決定する限り。
これは、独自の証明書を使用するよりもはるかに簡単です。または、明示的なユーザーアカウントを作成します（おそらく、有効なメールアドレスの提供を求めます）。たぶん私は銀行、Amazonなどのアカウントに同じマスターキーを使用しませんが、特にこれらの "ここに何かを投稿したい"状況では...完璧です。これ以上「ここに投稿したいことをグーグルやフェイスブックなどのサイトに知らせてください」ではありません。
SQRLは画期的な改善を提供しません。 QRコードは、短いコンテンツの配信に役立つ光学バーコード形式です。
SQRLが解決しようとしている「自動ログイン」状況では、代わりにモバイルに保存されているクライアント証明書を使用するだけで済みます。
仮定的にHTTPSページのQRバーコードcould以前にサーバーで認識されていたサーバー署名または暗号化バージョンのクライアント証明書（または類似の資格情報）を返しますが、なぜですか？資格情報の有効期限については？サイトは単に期限切れの資格を直接拒否することができます。
したがって、このプロトコルで私が抱えている最大のセキュリティ問題は 四角いホイールの再発明 です。
Update
新しい回答とコメントを読んで、成熟した既存のテクノロジーの単純な自動化によって、SQRLに似たことがどれほど簡単にできるかを指摘したいと思います。
- ウェブサイトは、CAPTCHAまたは同様の「私は人間です」の確認を求めます。ユーザーが準拠（POST済み）すると、Webサイトは
HTTP 403.7 - Client Certificate RequiredまたはVanilla 403エラーを返します。 - カスタム403ページは 設定するのに十分簡単 で、かなりきれいでユーザーフレンドリーです。 bootstrap多くのWebサイトで「Adobe Readerが必要です」というプロンプトと同様の方法で以下に必要な機能を使用することもできます。
- カスタム403ページには、カスタムブラウザープラグインが反応するマークアップが含まれています。このカスタムプラグインを「SQRL準拠」の精神で「S403L準拠」と呼びます。
- S403Lプラグインは、標準のクライアント証明書を生成します。これは、通常の暗号化されたブラウザー証明書キャッシュ（またはブラウザーのキーストアの暗号化に問題がある場合はサードパーティのキャッシュ）で保護されます。プラグインは、クライアント証明書の標準CSRを作成し、403マークアップで指定されたURLにCSRを送信します。 （例：
<s403l ref="https://www.example.com/S403L" />） - S403L準拠サーバーは、ユーザーのsession_id（Cookieまたはクエリ文字列から取得）を使用して、手順1で継続性を作成し、サーバーによって署名されたCSRを返します。一般的なサーバー認証は、サーバーによって署名された（したがって、ステップ1で要求された登録基準を満たした）クライアント証明書を受け入れます。
- S403Lプラグインは、署名されたクライアント証明書をブラウザのキャッシュに保存します。それ以降、プラグイン支援なしの標準ブラウザは、証明書の有効期限が切れるまで、標準のSSL/TLS方式でサーバーに「自動ログイン」できます。
SQRLの「モバイル」および「ビジュアル」の性質は、分離された2要素認証を提供せず、インターネットをナビゲートするために1つではなく2つのコンピューターが必要になるため、誤った方向付けのようなものです。デスクトップのUSBウェブカメラを専用のモニターに向けない限り。
パスワードと証明書の間のトレードオフは、セキュリティコミュニティで明確に定義されています。パスワードは人間の脳に収まります。証明書は人間の脳には適合しません（ 通常 ）が クレイジーエントロピー と優れたPKI管理機能（有効期限、失効、ポリシー拡張など）を持つことができます。 SQRLはどちらのキャンプにも完全に適合します。そして、それがそうであるように、それが人間ではないよりコンピュータのキャンプに向かって流れているならば-それは既存のX.509機能を繰り返すために何年もの開発とセキュリティ分析を持っています。
最初の質問についてお話ししたいと思います。「QRリーダーが危険にさらされていると、www.nsa-super-secret-place.gov/123の代わりにwww.google.comが表示されるという問題が考えられます」 ：
マスターキーは、Webサイトアドレス（FQDN）と共にHMACへのシードとして使用されます。そのため、QRコードは完全に異なるURLをエンコードする場合がありますが、プロトコルは通常www.google.com（例）に送信される認証コードを明らかにしません。
第二に、多くの貢献者はこのアイデアを解決する際に重要な目的を忘れています。
- サードパーティを使用しないことによる匿名性
- 使いやすさ
- 信頼できないコンピューターで秘密の資格情報を入力する必要はありません
プロトコルはこれらを完全に処理していると思います！
ただし、最初の目的から実際にもたらされる妥協点があります。認証に第三者が関与していない場合、どのようにして認証の詳細を取り消すことができますか？さらに、マスターキーのセキュリティは明らかな問題です。これは、HSMのようなチップで将来のモバイルデバイスによって十分に保護されることを想定しています。それまでは、キーは単なるファイルピンモバイルデバイスであり、パスワードで保護されていますが、PBDKF2を使用すると、実際にブルートフォースを実行するのが非常に遅くなります。