いつものように、スティーブギブソンに関連するものはすべてトラック一杯の塩で取ってください。必須のattrition.org リンク。

ギブソンのプロトコルの説明を見てみましょう。

• ログインの近くに表示されるQRコードプロンプトには、サイトの認証サービスのURLが含まれています。 URLには、安全に生成された長い乱数が含まれているため、ログインページのすべてのプレゼンテーションに異なるQRコードが表示されます。 （暗号サークルでは、この長い乱数は「ノンス」と呼ばれます。）

• スマートフォンのSQRL認証アプリは、ユーザーがキー入力したサイトのドメイン名を暗号化してハッシュします。 「サイト固有の公開鍵ペアを生成するためのマスターキー。

• アプリは、サイト固有の秘密鍵を使用して、QRコードに含まれるURL全体に暗号で署名します。 URLには安全な長いランダム番号（ナンス）が含まれているため、署名はそのサイトとQRコードに固有です。

• アプリはQRに安全なHTTPSPOSTクエリを発行しますサイトの認証サービスであるコードのURL。POSTは、サイト固有の公開キーと、QRコードのURLの一致する暗号署名を提供します。

• 認証Webサイトは、他のコンテンツを含まない標準のHTTP「200OK」を返すことにより、POSTクエリを受信して確認します。 SQRLアプリは、ユーザーが署名したQRコードの送信が成功したことを確認します。

• 認証サイトには、ユーザーを介してログインページから戻ってきたナンスを含むURLがあります。スマートフォン。また、そのURLの暗号化署名と、ユーザーのサイト固有の公開鍵があります。公開鍵を使用して、署名がURLに対して有効であることを確認します。これにより、署名を作成したユーザーが公開鍵に対応する秘密鍵を使用したことが確認できます。署名を確認した後、認証サイトは、認証されたユーザーをサイト固有の公開鍵で認識します。

私に飛びつく最大のことは、ユーザーによる”マスターキー”の使用です。プロトコルを正しく読んでいる場合、その単一のマスターキーがユーザーのオンラインID全体を制御します…

おそらく、このマスターキーはユーザーの電話のアプリケーションデータベースに保存されています。これにより、マスターキーを盗むために特別に設計されたマルウェアの形で巨大なギャップ攻撃ベクトルが開かれます。

では、パスワードが侵害された場合とマスターキーが侵害された場合の違いを比較してみましょう。パスワードマネージャーに保存されている長くて一意で非常にランダムなパスワードの適切なパスワード慣行に従っていると仮定すると、パスワードが侵害された場合は1つのパスワードを変更するだけです。マスターキーが侵害された場合はどうなりますか？マスターキーが侵害されたことを認識するために、認証したすべてのサイトを取得する必要があります。唯一の問題は、ユーザー名やサイトで認証する他の手段がないためです。電子メールアドレス、マスターキーを取り消そうとしているのが実際にあなたであることをサイトはどのように知るのでしょうか？

ギブソンから出てくるものと同様に、このSRQLスキームは非常に欠陥があり、従来よりもメリットがありません。メソッド。

Comme nts

• “パスワードの適切な慣行に従っている場合’ “は大きな警告であり、ほとんどのネチズンはそれを行いません’。SQRL ‘の約束の一部は、ユーザー’がベストプラクティスを常に把握する必要性を減らすことです。さらに、SQRL仕様では、マスターキーをマスターパスワードで暗号化して保存する必要があり、ブルートフォース攻撃は不可能です（1回の試行で最大60秒かかるように調整されています）。 SQRLは帯域外認証を促進するため、パスワードの取得は簡単ではないことがよくあります（つまり、ハッキングされたマシンのキーロガーは常に役立つとは限りません’）。したがって、完全な侵害の結果は高くなりますが、侵害の可能性はやや低くなります。
• SQRLにはまだ対処が必要な欠陥がある可能性がありますが、主張は、認証への既存のアプローチに見られる多くの問題を解決することを主張し、SQRLに対する批判は”何のメリットも提供しません”は、主張が盲目的に受け入れられることを期待するのではなく、これらの主張に対する反論を含める必要があります。
• >ギブソンから出てくるものと同じように、このSRQLスキームには大きな欠陥があり、従来の方法に勝る利点はありません。 —これは’質問に答えるのに役立たないようですが、実際には、誰がテクノロジーを思いついたのかという理由で、テクノロジーに問題があると感じています。欠陥として言及したポイントのいくつかは、実際には” spec “によって対処されています。たとえば、SQRL自体はマスターキーの保存方法について’言及していませんが、Steve Gibson ‘のコメントはモバイルであるということです。たとえば、クライアントは、実行に平均60秒かかるscryptを使用して、マスターパスワードで暗号化します。
• ギブソンは、マスターキーの保護に明示的に対処します。
• 2番目。 SQRLマスターキーが盗まれたのは、LastPassキーの 1つが盗まれたのと同じです。 ‘ 復号化されたLastPassパスワードデータベース全体が盗まれたと見なすのは、より良い例えではないでしょうか？

全体として、このプロトコルは既存のテクノロジーよりもセキュリティを強化しているようには見えません。オンラインでIDを保護するための最良の方法を探しているなら、これは間違いなくではありません。しかし、長所と短所を見てみましょう。

利点

“共有悪意のあるWebサイトが”あるサイトに提供された認証を使用して別のサイトにログインすることはできないという狭義のパスワード。

認証トークンに対するブルートフォース攻撃は実行不可能です。

資格情報はコンピューターに保存されません。これにより、次の小さなサブセットからユーザーを保護します。ワークステーション主導の攻撃。具体的には、コンピュータからパスワードを盗む攻撃から保護されます。ただし、セッションハイジャックやブラウザ乗っ取り攻撃からは保護されておらず、電話関連の攻撃にも影響を受けやすくなっています。 これについては後で詳しく説明します。

デメリット

この手法は、MITM攻撃やソーシャルエンジニアリングの影響を受けやすくなっています。おそらく、パスワードを含め、使用されている他のどの認証スキームよりもそうです。認証ステップとログイン開始ステップは、ユーザーに提示される方法や場所に関係なく、提示されたQRコードに対して電話が正しく認証されるという意味で、本質的に切断されています。

たとえば、フィッシングサイトは、ユーザーではなく攻撃者にログインする本物のログインQRコードを表示できます。ギブソンは、ユーザーが認証中に電話アプリに銀行、店舗、またはサイトの名前を表示することを確信しているため、攻撃を阻止するために十分な警戒を行います。歴史はこれがありそうもないことを示唆しており、より合理的な期待は、アプリで正しい名前を見ると、電話でおなじみのログイン要求をトリガーできたため、サイトが正当であるとユーザーに誤って思わせることです。パスワードのセキュリティに関してユーザーの頭にすでに打ち込まれている注意は、必ずしもこのような新しい認証技術につながるわけではありません。これにより、このアプリは本質的にソーシャルエンジニアリングに対する耐性が低くなる可能性があります。

この手法は、認証とIDの両方を組み合わせて、頻繁に紛失または盗難される物理オブジェクトにします。この意味で “パスワードというよりはパスポートのようなものです。あなたの電話を所有している人は、突然排他的にあなたのIDを所有します。攻撃者はあなたになりすますだけでなく、2番目の電話に2番目のコピーがありません（ありそうもない）、今あなたは自分自身を識別する能力を失っています。認証キーは取り消すことができないため、すべてのサイトからの帯域外リカバリがないと、IDをリカバリできません。また、帯域外リカバリが存在する場合でも、IDを所有しているユーザーと所有していないユーザーの2人のユーザーに直面すると、サイト運営者があなたを信頼する理由を理解するのが難しい場合があります。

この手法では、手動で他のトークンを作成しない限り、すべての認証トークンを1つのキーに結合します。これにより、1つのキーが攻撃者にとって非常にジューシーなターゲットになります。さらに、キーは携帯電話に保存されます。携帯電話は通常、笑えるほど多孔質の内部セキュリティを備えています。異常にジューシーなターゲットと標準以下のセキュリティを組み合わせても、安全にはなりません。

代替案

このスキームの最も問題のある側面は、利用可能な代替案と比較してどれほど劣っているのかです。

今日、広く受け入れられている最も安全なオプションは、lastpass、keepass、およびその他のブラウザに統合されたパスワードシステムです。特に、クライアント側の暗号化により、サードパーティを信頼する必要性が軽減されます。さらに重要なことに、ブラウザの統合により、フィッシングは事実上不可能になります。 LastPassまたはKeePassは、正しいドメインから提供された場合にのみパスワードを入力します。つまり、悪意のあるサイトが提示された場合、ユーザーは自分のパスワードにアクセスできなくなります。

さらに、LastPassは最近機能を追加しましたこれにより、ユーザーはグローバルに一意ではないパスワードを変更する必要があります。これにより、パスワードの再利用を防ぐことができます。つまり、Gibsonの手法の主な利点は、現在、既存のサイトでこのツールを使用することで、彼のスキームが示す不安を増すことなく簡単に得られます。

電話または同様のデバイスを使用する既存の第2要素認証スキームは、デバイスが盗まれた場合にIDの盗難に対してすぐに脆弱にならないような方法で、今日のユーザーログインを保護するのに役立ちます。二要素認証のセキュリティは、デバイスもパスワードも、他のユーザーなしで盗まれた場合は使用できないという事実にあります。ギブソンの手法は、二要素スキームに含まれることにほとんど抵抗があり、このレベルの保護を実現します。

TL; DR：

ギブソンの認証技術は、それが課す追加のセキュリティコストを克服するのに十分な利益を生み出しません。これらのコストはスキーム自体の基本的な部分であり、設計全体を廃棄せずに解決することはできないでしょう。

「何もないよりはましだ」と主張することはできますが、「主張することはできません」。

ギブソンの最新情報

ギブソンは最近、これが大きな批判であったため、フィッシングに対する追加の保護を発表しました。それらの保護は次のとおりです。QRコードや携帯電話などを使用しておらず、代わりにシステムに認証エージェント（ブラウザ内など）がある場合、サーバーは認証を確認するためにチェックできます。応答は認証要求と同じIPから送信されます。これは問題ありませんが、このプロトコルの全体的な目的は、IDを携帯電話に移動することです。プロトコルを使用する唯一の安全な方法がそのコアを使用しないことである場合機能があれば、おそらく私たちが達成しようとしていることを再考する必要があります。

理論的には、携帯電話が知っている場合に限り、携帯電話を使い続けることができます。 コンピュータと同じIPを使用していたこと。もちろん、コンピュータのIPアドレスがわからないため、わかりません。

より良い解決策

前述のように、認証手段がブラウザにある場合は、すると、フィッシングの問題全体が、の努力や検証なしですぐに解決されます。ユーザー。サイトの認証トークンがドメイン名に関連付けられているため、能力の低いユーザーでさえ、間違ったサイトへの認証に騙されることはありません。ブラウザが勝ちます。 t間違ったドメインへの認証を許可します。これは現在すでに使用されている手法であり、完全に自動化されており、サイトの協力やユーザー側のインテリジェンスを必要としません。

この方法は、2番目の認証要素を必要とすることで強化できます。 （携帯電話の時変キーなど）これもすでに利用可能であり、今日使用されています。これにより、（特に）宛先サイトまたは会社側の混乱からユーザーを保護します。

ブラウザ側の認証がクライアントワークステーションの攻撃に対して脆弱であるという懸念について：これは真実ですが、ブラウザが侵害された場合は、そうではありません。そのブラウザの使用は、使用する認証メカニズムに関係なく、安全です。マルウェアの作成者は、非常に安全な手法を使用して自分で認証するのを待ってから、必要なトラフィックを”自分のあなたのアカウント、すべてあなたが何か間違いを見ることなく。 SQRLも他の認証システムも、侵害されたブラウザのユーザーを保護することはできません。ドアロックだけで住宅火災からユーザーを保護することができます。耐火ロックを購入することは解決策ではありません。

次のステップ

「なりすましからの保護の絶対的な保証を探している場合次に、Fido U2Fトークンを確認します。この標準は、SQRLが不足している場合に役立ち、MITM（フィッシングなど）攻撃に対する耐性を保証します。これは、ユーザーだけでなくチャネルも認証することで実現されます。 「（a）トークンがないとアカウントを認証できません。また、（b）トークンは、接続されているマシンへの接続を認証するためにのみ使用できます」。詳細については、この回答を参照してください。

コメント

• 最初のポイントについて：私が理解している限り、これは考えられていたものであり、1つのオプションは、認証対象のWebサイトにリダイレクトの責任を負わせることです。そのため、ログインすると、攻撃者ではなく、実際の銀行の’ページにリダイレクトされます。 2番目のポイントについては、LastPassのようなツールのユーザーでも同じことが今日起こります。何らかの保護メカニズム（PINなど）を設定しない限り、すべてのパスワードも盗まれます。 ‘がSQRLにも当てはまらないのはなぜですか？また、仕様から理解できる限り、ユーザーは紙の上でも（QRコードとして）自分のIDをバックアップできます。
• そして3番目のポイントについて：同じことが、’複数のWebサイトで単一のユーザー名/パスワードを使用するだけで、パスワードマネージャーを使用しません。または、”アイデンティティ”が複数のウェブサイトに分散しているが、1つの場所に保存されているパスワードマネージャーのユーザーの場合（LastPass ‘サーバー、1Passwordデータベースなど）。したがって、’は実際にはSQRLの欠陥ではありません。全体として、SQRLについて読むほど、現在の代替案と比較してSQRLの利点がわかります。スティーブギブソンについてあなたが言うと言ってください、しかしSQRLは本当に私にとって良い選択肢のようです。
• “注意はすでに頭に打ち込まれていますパスワードセキュリティに関するユーザーは、必ずしもこのような新しい認証技術に変換されるとは限りません。 。 。” これは優れた点であり、戦いはすでにマーケティングに負けています。 QRコードは、潜在的な攻撃ベクトルとしてではなく、物事を成し遂げるための簡単な方法と見なされています。少なくともユーザー名とパスワードのペアは、マーケティングツールではなく、認証メカニズムとして最初に使用されました。
• @jpkrohling：パスワードマネージャーに関しては、そのようなソフトウェアのほとんどのユーザーはマスターパスワードを保存しないと思います。彼らがそれがどれほど危険であるかを知っているという理由だけで、彼らのモバイルデバイス上で。安全な場所にマスターパスワードの物理的なコピーが1つありますが、電子的なコピーはありません。私のマスターパスワードへのアクセスを許可する攻撃は、サイトのパスワードを危険にさらす攻撃とは異なり、その可能性ははるかに低くなります。 （主に、パスワードデータベースを攻撃すると、大規模な侵害サイトではなく、個人的に攻撃することになります。）
• @jpkrohlingLastPassもKeePassもマスターパスワードをどこにも保存しません。 ‘はパスワードデータベースのロックを解除するために使用されますが、’は保存されません。これは、それ自体がどこでも使用される単一のキーを持つこととは根本的に異なります。

SQRLは確かに欠陥がないわけではありませんが、セキュリティと（そしてこれは重要な）使いやすさの点で、今日Webで広く使用されているほとんどの主要な認証ソリューションよりも確かに優れています。説明させてください。

誤解

まず、この質問の他の回答のいくつかに存在する誤解のいくつかを明らかにしましょう。これらの回答の多くは古く、SQRLドキュメントが変更される前に書かれています。それらに提示された問題に対処する一方で、他の多くの広く使用されている既存の認証ソリューションにも存在するSQRLの欠陥を過度に強調し、その利点を無視しているようです。ここでいくつかの誤解を解消しましょう。私たち？

神話：SQRLはQRコードをスキャンする必要があります

これは単に真実ではありません。QRコードは便利ですこれにより、ユーザーがSQRLクライアントソフトウェアをセットアップしていないコンピューターでSQRLを使いやすくなります。 SQRLのWebサイトには、次のように記載されています。

3つの方法…オプションのスマートフォン：

このシステムの開発の元々のインスピレーションは、ウェブサイトのログインページでQRコードをスキャンするスマートフォンでしたが、そのモデルに少し追加するだけで、さらに2つの重要な操作モードが可能になります。 QRコード画像もQRコードにエンコードされているのと同じURLへのクリック可能なリンクにします。これにより、3つのログイン方法が得られます。

• スマートフォンでコードをスキャンします。上記のモデルでは、ユーザーのスマートフォンがWebサイトのログインページに表示されるQRコードをスキャンし、ユーザーはそのサイトにログインします。
• TAPスマートフォンのコード：スマートフォンのウェブサイトにログインするには、視覚的なSQRLコードもURLスタイルのリンクである場合（スキームとしてsqrl：//を使用）スマートフォンにインストールされたSQRLアプリはそのリンクを受信し、ユーザーをスマートフォンのサイトに安全にログインさせます。
• デスクトップまたはラップトップの画面でコードをクリックします：デスクトップまたはラップトップシステムでSQRLシステムを使用するには、デスクトップSQRLアプリケーションがインストールされ、sqrl：//リンクを受信するように登録されます。 （これは、電子メールプログラムがmailto：リンクを受信するために登録する方法に似ています。）これにより、ユーザーはスマートフォンで使用しているのと同じソリューションをデスクトップで使用できます。 WebサイトがSQRLコードを提供している場合、ユーザーはマウスカーソルでコードをクリックするだけで、ローカルにインストールされたSQRLアプリがポップアップし、SQRLパスワードの入力を求め、ドメインを確認してからログインします。

神話：SQRLマスターキーは完全に暗号化されず、保護されていない状態で携帯電話に保存されます

なぜ一部の人がこれを作成したのかわかりませんSQRLマスターキーは、パスワードデータベースを保護するのとほぼ同じ方法で保護されます。つまり、強力なマスターパスワードを使用します。ユーザーの電話を盗んだ場合、マスターパスワードも持っていない限り、オンラインIDに自動的にアクセスすることはできません。キー管理の詳細については、 SQRLクライアントのページで説明しています- SQRLのWebサイトのサイドキー管理。

神話：マスターキーが盗まれた場合、ログイン資格情報を変更することはできません

これも誤りです。SQRLキーが侵害された場合に本物のアカウント所有者がログイン資格情報を更新できるようにする組み込みの方法を提供します。この機能はIDロックと呼ばれます：

「IDロック」はIDの変更を防ぎます&は回復を許可します：これはまた、独自の詳細な説明ページ「 IDロックプロトコル」（このページの下部にあるリンクブロックの4ページ）に値するほど重要です。ユーザーのIDは、WebサーバーSQRLcで確立されています。 lientはそのIDを変更できないです。これは、最悪の事態が発生し、非常に弱くて推測しやすいパスワードが使用された場合、またはユーザーの電話またはデスクトップがハッキングされてIDマスターキーとパスワードを取得した場合、悪意のある第三者がユーザーのオンラインIDを変更して自分のオンラインアカウントからロックアウトすることはできません。さらに、通常はオフラインの「IDロック解除キー」をロードすることで、IDの真の所有者は、紛失または盗難にあったオンラインIDを廃止して置き換え、本質的に元に戻すことができます。攻撃者からの、以前のIDを役に立たなくします。

妥当：SQRLはフィッシングに対してより脆弱です既存の認証ソリューション

わかりました。これは、実際には部分的に真実です。 QRコードをスキャンしてSQRLを使用する場合、フィッシングに対する保護はほとんどありません。ユーザーがブラウザのURLバーに表示されるWebサイトがSQRLクライアントアプリによって表示されるWebサイトと同じであることを確認しない限り、攻撃者のログインセッションを承認している可能性があります。これはパスワードよりも優れています。彼らは、パスワードを変更するまで、フィッシャーに自分のアカウント（および同じパスワードを共有する他の場所にある他のアカウント）への永続的なアクセスを許可しますが、U2Fキーのようなユーザーのブラウザと統合する他のソリューションほど良くはありません、WebAuthn、クライアント証明書、および（特定の条件下で）パスワードマネージャー。

ただし、「ログインしているのと同じデバイスでSQRLクライアントを使用している場合、SQRLにはいくつかの保護があります。これらの保護については、SQRLのウェブサイトの SQRLがフィッシング攻撃を阻止する方法のセクションで説明されています。また、SQRLをブラウザと（おそらくプラグインを介して）統合して、フィッシング攻撃に対するより強力な保護を提供する可能性もあります。WebAuthnやクライアント証明書などのソリューションと同等です。

全体的にSQRLをランク付けします。フィッシング対策のパスワードマネージャーとほぼ同じレベル。ユーザーがログオンしているのと同じデバイスにインストールすると、フィッシングに対する強力な保護を提供する可能性がありますが、別のデバイスにインストールすると最小限の保護しか提供されません。

代替手段との比較

ここで、SQRLを既存の広く使用されている認証ソリューションと比較してみましょう。

パスワード

SQRLは、多くの点でパスワードよりもはるかに優れています。一度設定すると便利になるだけでなく、ユーザーはサイトごとに複数の異なるパスワードを覚えたり再入力したりすることを心配する必要がないため、パスワードの再利用、脆弱なパスワード、キーロギング、およびある程度のフィッシングからも保護されます。

デメリットSQRLはパスワードと比較して、Webサイト運営者にとっては実装が難しく、広く使用されておらず、最初のセットアップに時間がかかり、新しいデバイスに転送するためにある程度の労力が必要であり、マスターキーが盗まれた場合のすべてのユーザーのアカウント（ただし、この最後のパスワードユーザーがすべてのサイトで同じパスワードを使用する場合は、パスワードにも当てはまります。

パスワードマネージャー

多くの点で、SQRLはパスワードマネージャーと非常によく似ています。これらは両方とも、ユーザーと個々のサービス間の一種の認証プロキシとして機能する単一の集中型トラストアンカーを提供します。 SQRLがパスワードマネージャーよりも優れている方法はいくつかあります。

SQRLがパスワードマネージャーよりも優れていると思う主な利点は、信頼されていないコンピューターや部分的に信頼されているコンピューターでの使用がより簡単で安全であることです。たとえば、ユーザーが公共の図書館のコンピューターを使用してWebサイトにログインしたい場合、パスワードマネージャーを使用すると、電話でそのサイトのパスワードにアクセスして手動でコンピューターに再入力するか、自分のサイトをダウンロードする必要があります。パスワードマネージャーとパスワードデータベースをライブラリコンピューターにインストールし、マスターパスワードを使用してデータベースのロックを解除してから、ログインします。最初のシナリオはユーザーにとって不便であり、その1つのサイトのユーザーのプレーンテキストパスワードを信頼できないコンピューターに公開します。キーロガーを含む、信頼できないコンピューター上のマルウェア）。 2番目のシナリオは、不便であり、ユーザーの復号化されたパスワードデータベース全体とマスターパスワードを信頼できないコンピューターに公開するため、さらに悪化します。 SQRLを使用すると、ユーザーは信頼できないコンピューターの画面でQRコードをスキャンするだけで済みます。これはユーザーにとってはるかに便利であり、信頼できないコンピューターに1回のログインセッション（パスワードなどの再利用可能な資格情報なし）を公開するだけです。 。

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の最初の要素であるパスワードに代わるものです。 SQRLでは、OTPコードやFIDOU2Fキーなどの他の追加の手段を引き続き使用できます。

WebAuthn

ここで 興味深い点があります。 WebAuthn は、WebサイトがWeb上の公開鍵を使用してユーザーを認証するために使用できる標準APIを提供するように設計された新しい（SQRLよりも新しい）W3C標準です。SQRLと同様に、 ユーザーの電話を使用して外部デバイスでログインセッションを認証するに加えて、他のいくつかの認証方法（2次セキュリティキーなど）をサポートします。 。

これは、少なくともセキュリティの観点から、SQRLが最終的に一致する場所です。 WebAuthnは、SQRLと同じパスワードの再利用、脆弱なパスワード、キーロガーに対する保護を提供するだけでなく、ログインを承認するときにユーザーのブラウザと統合することで、フィッシングに対するさらに強力な保護を提供します。 PCのセッションでは、ユーザーは以前にオーセンティケーターのクライアントソフトウェアをセットアップしていません。これが可能なのは、その状況では、WebAuthnが、ユーザーが使用しているWebサイトと一方向のQRコードを介して通信する代わりに、BlutoothやNFCなどの双方向通信プロトコルを使用してユーザーのブラウザーと直接通信するためです。

使いやすさの観点からすると、状況はもう少し複雑です。少なくとも表面的には、WebAuthnが再び勝ちます。これはW3C標準であり、すでに複数のブラウザに実装されているためです、理論的には、ユーザーはサードパーティのソフトウェアをインストールしなくてもすぐにWebAuthnの使用を開始できます。ただし、実際には、ほとんどの既存のWebAuthn実装は、第2要素認証の形式またはユーザーの再認証方法としての使用に重点を置いています。以前に異なるログイン方法（通常はパスワード）を介して同じデバイスにサインインしたユーザー。主要な認証要素として、WebAuthnはまだ実行可能な実装に欠けています。

その他のマイナーな考慮事項には、SQRLがビルマスターキーが盗まれた場合にアカウントのキーをローテーションするt-inメソッド。一方、WebAuthnは、キーを取り消すための独自のシステムを実装するためにWebサイトに依存しており、WebAuthnは特定のオプションのハードウェア（BluetoothやNFCなど）を順番に必要とします。 SQRLは、ディスプレイが機能しているどのマシンでも機能しますが、リモートマシンに対して認証するためです。

全体として、WebAuthnによってSQRLが最終的に廃止される可能性が非常に高いと思います。 SQRLには今のところ少し余裕があるかもしれませんが、WebAuthnには、ブラウザーベンダー、サイトオペレーター、およびその他のサードパーティ組織（W3Cなど）からの強力な支援があります。 WebAuthnが主要な認証要素としての使用を可能にするいくつかの実装を取得すると、Webを非常に迅速に引き継ぐようになると思います。

警告

SQRLはまだ活発に開発中です。したがって、この回答に示されている資料は変更される可能性があります。開発が進むにつれて、この回答の脆弱性と不確実性のいくつかが解決されることを期待しています。議論のほとんどは現在、grc.comの SQRLニュースグループで行われています。

SQRLは、ユーザー名の問題に対する便利なソリューションです。 / passwordparadox。（つまり、利便性とセキュリティのトレードオフ）サードパーティを使用しない。これは、最も一般的な認証モデル（ユーザー名&パスワード）の簡単な代替手段を提供し、セキュリティを実質的に損なうことはありません。 セキュリティを意識している限り、実質的に今日使用されている一般的な認証モデルと同じくらい安全です。 SQRLを使用している場合、これを多要素認証と組み合わせるなどのセキュリティのベストプラクティスに従えないという意味ではありません。

SQRLのポイントを見逃さないことが重要です。 SQRL自体がセキュリティの向上または低下をもたらす必要はありません。コンピュータ/電話自体が侵害された場合、またはユーザーがだまされた場合フィッシングされている場合、これはSQRL自体の直接的な障害ではなく、サイドチャネル攻撃です。 従来のすべての認証方法には、サイドチャネル攻撃のこの問題があります壊れないワンタイムパッドもサイドチャネル攻撃に対して脆弱ですパッド自体の侵害、周囲のセキュリティや実装の悪さなど。

SteveGibsonのに関するアイデアの元の提案を聞いた場合ポッドキャストの後にQ & Aが続き、このスタックスレッドで提起された懸念の多くが回答されました。また、スティーブは、この非常に「単純」で「独創的」（彼の言葉）のアイデアは、これが安全な解決策であるかどうかがわかるので、セキュリティの専門家が「精査」して「槌で打つ」必要があると自分自身で言いました。

結論として、SQRLに反対する議論のほとんどは、SQRL自体の領域外にあり、代わりに、不十分なセキュリティを実践している人間の問題です。 SQRLは、従来の認証方法にはない問題の新しい分類を導入していません。

SQRLは、セキュリティを重視する人々が適切に使用すれば優れています。 利便性とセキュリティの間には常にトレードオフがあることを理解する必要があります、このソリューションはおそらく私が見た2つの中で最高のバランス。

コメント

• Ansichartに感謝します。しかし、’既存の認証ソリューションは、SQRLと同等以上のセキュリティ機能を保持し、自動化を使用してユーザーの利便性を向上させることはできませんか？ SQRL ‘のユーザーの利便性の基本的な特性は、自動化のためにないですか？ユーザーが同じことをする2つのブラックボックスを持っているかどうかを尋ねます。 1つは”成熟した”とラベル付けされ、もう1つは” SQRL そしてそれらは両方とも設計/自動化でき、ボックスの外側に同じインターフェース/ボタンがあります-SQRLはどのような付加価値を提供しますか？
• パスワードのパラドックスの問題を解決しますサードパーティを使用する必要はありません。
• なるほど。したがって、誰かが’サードパーティによるシングルサインオンのリスクを望まず、’でパスワードを生成/保存しない場合パスワードマネージャー、SQRLはステップアップできます。ただし、SQRLがモバイルブラックボックスであり、SQRLIDの再生成/保存に使用されるマスターキーのロックを解除するためのパスワードを要求し、クライアントのバックチャネルリンクを実行する場合’ s cookie / QR service_id with server ‘は、ログインするためにSQRLIDを記録しました。これは、同じバックチャネルを介して自動ログインするモバイルパスワードマネージャーとはどのように異なるモバイルブラックボックスですか。または、同じバックチャネルを介して自動生成&ログインする2者間モバイルクライアント証明書プラグイン？
• 元の投稿を大幅に編集しました私がそれを誇張しすぎたかもしれないので、いくつかの2番目の考慮と他の人が言っていることにもっとよく読んだ後。携帯電話を中心に据えることで問題がシフトし、携帯電話のセキュリティを強化することがより重要になると思います。スティーブギブソンもこれをQ &ポッドキャストで取り上げています。

他のコメントにはある程度同意しますが、いくつかのメリットがあると思います。

SQRLを有効にするには、マスターキーを作成して携帯電話に保存する必要があります。 。完了。その秒から、「SQRL」を使用するすべてのWebサイトにログインできるようになります。そして、それ以上の情報を提供しないことに決めた限り、それは匿名のログインになります。

これは、独自の証明書を使用するよりもはるかに簡単です。または明示的なユーザーアカウントを作成する（おそらく有効な電子メールアドレスを提供するように求めます）。たぶん私は私の銀行、アマゾン、…アカウントに同じマスターキーを使用しないでしょう-しかし特にこれらの「私はここに何かを投稿したい」状況のために…完璧です。 「ここに投稿したいことをグーグルやフェイスブックなどのサイトに知らせてください」はもう必要ありません。

コメント

• I ‘これが有効なポイントであるかどうかわからない-‘匿名ログインを許可する場合、そもそもなぜログインに煩わされるのでしょうか。一部のスパムを防ぐには、単純なキャプチャで十分です。
• 匿名ログインはあなたであるため、あなたの身元に関する情報の提供を拒否するだけです。だれもそれをスプーフィングすることはできません。
• WindowsCardSpaceの半ば焼き直しのように聞こえます。
• または、ログインしたことがないユーザーにログインしている場合は、キャプチャ以前。
• ” SQRLを有効にするには、マスターキーを作成して携帯電話に保存する必要があります。”実際には、’必要はありません。必要なのは、sqrl：// URLを開くことができるPC上のソフトウェアだけです。

SQRLは画期的な改善を提供しません。 QRコードは、短いコンテンツ配信に役立つ光学バーコード形式です。これ以上はありません。

SQRLが解決しようとしている「自動ログイン」状況では、代わりにモバイルに保存されているクライアント証明書を使用できます。

仮にHTTPSページのQRバーコードは、サーバーが以前に知っていたクライアント証明書（または同様の資格情報）のサーバー署名または暗号化バージョンを 返すことができますが、なぜですか？資格情報の有効期限は？サイトは、期限切れの資格情報を直接拒否するだけで済みます。

つまり、最大のセキュリティの問題プロトコルは次のとおりです。スクエアホイールの再発明。

Update

新しい回答とコメントを読んで、SQRLと同様のことを行うのがいかに簡単かを指摘したいと思います。 成熟した既存のテクノロジーの単純な自動化：

1. Webサイトは、CAPTCHAまたは同様の「人間」の検証を要求します。ユーザーが準拠（POST）すると、WebサイトはHTTP 403.7 - Client Certificate Requiredまたはバニラ403エラーを返します。
2. カスタム403ページはセットアップが簡単で、非常に美しく、ユーザーフレンドリーです。多くのWebサイトの「AdobeReaderrequired」プロンプトと同様の方法で、以下に必要な機能をブートストラップすることもできます。
3. カスタム403ページには、カスタムブラウザプラグインが反応するマークアップが含まれています。このカスタムプラグインを「SQRL準拠」の精神で「S403L準拠」と呼びましょう。
4. S403Lプラグインは、標準のクライアント証明書を生成します。これは、通常の暗号化されたブラウザ証明書キャッシュ（または3番目のブラウザのキーストア暗号化がうまくいかない場合はパーティキャッシュ）プラグインはクライアント証明書の標準CSRを作成し、403マークアップで指定されたURLにCSRを送信します（例：<s403l ref="https://www.example.com/S403L" />）
5. S403L準拠のサーバーは、ユーザーのsession_id（Cookieまたはクエリ文字列から取得）を使用して手順1との継続性を作成し、サーバーによって署名されたCSRを返します。一般的なサーバー認証は、サーバーによって署名された（したがって、ステップ1で要求された登録基準を満たした）すべてのクライアント証明書を受け入れます。
6. S403Lプラグインは、署名されたクライアント証明書をブラウザーのキャッシュに保存します。その後、プラグイン支援のない標準ブラウザは、証明書の有効期限が切れるまで、標準のSSL / TLS方式でサーバーに「自動ログイン」できます。

「モバイル」および「ビジュアル」の性質SQRLは、分離された2要素認証を提供せず、インターネットをナビゲートするために1台ではなく2台のコンピューターが必要になるため、方向が間違っています。デスクトップのUSBWebサイトを専用のモニターに向けない限り。

パスワードと証明書のトレードオフは、セキュリティコミュニティで明確に定義されています。パスワードは人間の脳に適合し、証明書は適合しません。人間の脳（通常）ですが、クレイジーエントロピーと優れたPKI管理機能（有効期限、失効、ポリシー拡張など）。 SQRLはどちらのキャンプにもきれいに収まります。そして、それが「人間的ではない、よりコンピュータのキャンプに向かっているように見える」場合、既存のX.509機能を繰り返すための開発とセキュリティ分析が何年もあります。

コメント

• >は、代わりにモバイルに保存されているクライアント証明書を使用するだけで済みます。—ただし、このテクノロジーはモバイルとデスクトップの両方に何年も存在し、’は思ったほど普及していません。また、クライアント証明書とは異なり、SQRLでは’ ” SQRLIDを作成するために実際のIDを証明する必要はありません”。必要に応じて、必要な数のIDを作成できます。これは、クライアント証明書と比較した場合の利点は、認証プロトコル’側から匿名性があることです。
• @jpkrohlingクライアント証明書はよくある誤解です。使用するにはIDの開示が必要です。これは、グローバルに交換可能なトラストチェーンを使用するための商用署名機関の要件です。実際には、クライアント証明書は、クライアントによって作成され、特定のサーバーによって署名された匿名の CSR であり、必要な基準（CAPTCHA、以前のアカウント、等）。証明書には有効期限が組み込まれている場合もあります。 Type 40-L QRバーコードは、必要に応じて1KBX.509クライアント証明書をディスパッチ/保存できます。
• わかりました、本当です。この観点から、クライアント（モバイルアプリなど）は、ユーザーが登録しているWebサイトごとにクライアント証明書を生成している可能性があります。これは、一部の情報をハッシュするよりも費用がかかるように聞こえますが、興味深い解決策になる可能性があります。いずれにせよ、私はまだ’ SQRLが役に立たないより悪いというあなたの主張に同意しません。
• 私はおそらくその言葉遣いに厳しく、それを削除します。しかし、私は’ SQRLをネゴシエートされたクライアント資格情報を配布するためのよりセクシーな方法以外のものとは考えていません。 ‘が、成熟した認証スキームによって対処される微妙な問題のいくつかを解決しなかったもの。パスワードマネージャーは面倒です（’私はパラノイアなので、ブラウザーの統合に煩わされることはありません）が、私と1人だけが知っていますWebサイトは、暗号化されたキーストアで各ワンショットパスワードを共有します。 ‘新しいハッシュ/認証スキームについて心配する必要はありません。パスワードマネージャーがパスワードの生成に使用するPRNG / TRNGの品質だけを気にする必要があります。
• @LateralFractal ‘が新しいかどうかは誰が気にしますか？ SQRLを使用すると、第1者が第2者または第2者のセキュリティを侵害した可能性のある第三者に秘密を公開しないユーザーフレンドリーな認証が可能になります’。 ‘は、これまで誰も解決できなかった現実世界の問題を解決する試みです。

最初の質問に答えたいと思います。「私が考えることができる問題の1つは、QRリーダーが危険にさらされているかどうか、www.google.comを表示することです。 www.nsa-super-secret-place.gov/123 “の代わりに：

マスターキーは、Webサイトアドレス（FQDN）とともにHMACへのシードとして使用されます。したがって、QRコードは完全に異なるURLをエンコードする場合がありますが、プロトコルは通常www.google.com（例）に送信される認証コードを明らかにしません。

次に、寄稿者の多くは、このアイデアを実行する際の主要な目的を忘れています。

1. サードパーティを使用しないことによる匿名性
2. 使いやすさ
3. 信頼できないコンピューターで秘密の資格情報を入力する必要はありません

プロトコルはこれらに完全に対応していると思います！

ただし、実際には妥協点があります最初のオブジェクトから来ます。認証にサードパーティが関与していない場合、認証の詳細を取り消すにはどうすればよいですか？さらに、マスターキーのセキュリティは明らかな懸念事項です。私はこれがHSMのようなチップ内の将来のモバイルデバイスによって十分に保護されることを想定しています。それまでは、キーはパスワードで保護されたファイルピンモバイルデバイスですが、PBDKF2を使用すると、実際にブルートフォース攻撃を行うのが非常に遅くなります。

コメント

• 繰り返しますが、このアイデアの’の新機能は何ですか？私には、現在は機能していないWindowsCardSpaceの原始的なバリエーションのようです。
• はい、CardSpaceについては正しいです。次に、同じくMicrosoftが所有するU-Proveがあります。問題は、信頼できないコンピューター（インターネットカフェや友人のコンピューター）でCardSpaceまたはU-Proveをどのように使用するかです。それがスティーブが付け加えたものです。
• ああ、わかりました。’私が欠けていたものです。 @TerryChiaは、これがユーザーキーの失効メカニズムのない非スターターであることに同意します。
• @Xanderユーザーキーの失効メカニズムがあります。 grc.com/sqrl/idlock.htm