Fido U2Fまたは同様のものをプライマリ認証方法として使用していますか？
私はしばらくこれについて疑問に思っていましたが、Webで多くを見つけることができなかったので、このトピックについての理解を深めるために誰かが私を正しい方向に向けてくれることを願っています。
Fido U2Fデバイスのようなものをプライマリ認証方法として使用することは実行可能/安全でしょうか？
これまでにクライアント側のSSL証明書を使用してきましたが、もちろんクライアントの構成が必要です。標準のスマートカードを使用しても同じことが可能であることは知っていますが、もちろん現在ほとんどのデバイスにスマートカードリーダーがありません。 Fidoキーは、リーダーを必要とせずに秘密キーのペアを持ち運ぶのに最適なフォームファクターのように見えます。モバイルデバイスの場合は、NFC（新しいyubikeyが行うように）または組み込みの「オンザゴー」アダプターを使用できます。
これで、キーが盗まれる問題を理解しましたが、ほとんどのスマートカードと同様に、いくつかのPINを使用してキーのロックを解除することで解決/軽減できると思います。追加のセキュリティ対策として、 Webサイトでは、「第2要素」としてパスワードを要求する可能性があります。これは、当然、パスワードを覚えておく必要があることを意味しますが、非常に重要なシステムでは、完全に保護する必要があります。
私の希望では、このようなものは、セキュリティの観点での大幅な改善と、ログインの摩擦（ユーザーの場合）と複雑さ（実装者の場合）の両方を大幅に改善するのに役立ちます。
さて、この方法で大きな問題/障害はありますか？ブラウザはすでに認証にスマートカードを使用できるように思えますが、欠けているのは実際のデバイスを開発することだけです（PINをFidoデバイスに追加する方法がないと仮定） ..
確かに！標準のスマートカードPKIソリューション（SSLクライアント証明書、アプレット、ブラウザープラグイン、ミドルウェア...）とFIDO U2F簡易PKIソリューションの両方を使用/構築/展開しています。FIDOU2Fは、主要な認証方法としても機能します。
これは、ユーザー名とFIDO U2Fを使用した共有ログインURLページ、またはFIDO U2Fを使用したユーザーごとの一意のログインURL（ユーザーに確認を求めずに識別する）を使用して、プライマリ認証として使用できます。もう1つの非標準的な使用例ですが、ごく少数のユーザーに対処するだけでよい場合は簡単な解決策です。「ユーザー名を要求する部分」をスキップすることもできます（サーバーは、既知のすべてのキーハンドルをデバイスに送信するだけで、適切なものを見つけることができます1）。
PIN保護の追加については、onlykeyのようなローカルPINエントリ保護（ https://crp.to/ p / ）
拡張機能を備えた独自のFIDO U2F API互換ソリューションを開発して、PIN=保護、共有ID、簡略化された暗号化を追加することもできます...私は、そのようなソリューションに取り組んでいる数少ない「狂犬」の1人です。
注/注意：FIDO U2FはChromeで動作します。Firefoxの組み込みサポートは数週間で利用可能になるはずです。すでにFIDO U2F USBセキュリティキーがあります= NFC=カード/キー。BluetoothLow Energy（BLE）デバイスも間もなく登場します。
唯一の要素としてのU2Fは、所有証明が十分である環境（RFIDカードのドアなど）でのみ有効であり、ユーザー名が実際に（私の意見では）他の人が試用することを阻止するためのまともな方法である後、U2Fを最初の要素として使用します私たちがサインインしようとしている人が彼であると言っている可能性があるという現実的な仮定がない限り（実際、私はいくつかの趣味のプロジェクトで試していることです）、かなり素晴らしいニュースがあります。
ブラウザーのU2F APIは、Webauthnに置き換えられています。Webauthnは、U2Fだけでなく、Webで可能なより多くの/異なるタイプの認証も含むAPIです。
ここで特に重要なのは、U2Fの後継であるFido2です。これは、その名前が示すように、U2Fと同じFIDOアライアンスによって作成されました。
WebauthnはFido2がもたらす2つの重要な新しいものを追加します：
ユーザーの確認、つまり、必要に応じて、デバイスに応じて「ローカルロック解除パスワード」（最大255文字のUnicode文字）のような「PIN」を入力するか、生体認証（指紋チェックなど）を実行する必要がありますユーザー認証の使用を積極的に妨げない場所で認証するため。単にWebauthnには、Webサイトが要求できるユーザー認証のための3つのオプションがあります
推奨、デフォルト、つまり基本的にはユーザーを確認できる場合は確認してくださいが、確認できない場合（そのためのデータがないか、U2Fだけのような確認のないデバイスを扱っているため） 、ユーザーの存在を確認するだけ（ボタンを押す）
デバイスが検証を行うことができるが、それを行うためのデータ（ピン/バイオメトリなど）がない場合は、ユーザーにそのようなデータを作成するように要求し、デバイスが検証を行えない場合は、それを拒否する必要があります。
推奨されません。これは、検証を完全にバイパスして摩擦を減らしようとするだけです。これは、2番目のシナリオまたはpossion-only-factorシナリオで役立ちます。
常駐キー。 1「問題」U2Fとwebauthnの「通常」モードでは、認証が必要な人物を知っている必要があるため、適切な登録データセット（ほとんどの場合はキーハンドル）を持ち込むことができます。一部のPRNG/KDFトリックは、実際にデバイス自体に秘密キーまたはキーペアを保存するのではなく、内部シークレットのみを保存するために使用され、Webサイトは、いくつかのアルゴリズムによって実際のキーペアに関連付けられている保存するキーハンドルを取得します。すべてのサイトがデバイスの静的シークレットを使用してキーを作成するために必要な一意のデータを保存する必要があるため、1つのデバイスのペア。
常駐キーとは、文字通りその名前が示すとおり、デバイスに常駐するキーです。ストレージは無制限ではなく、さらに安全なストレージなので、制限があります。 Yubikey 5シリーズでは、25の常駐キー、ソロ50が許可されています。私が知っている限り、常に確認が必要になるため、常駐キーを使用すると、文字通りWebサイトのボタンをクリックするだけで、ピンを要求するデバイスにチャレンジを発行します。 Webサイトに複数の常駐キーがある場合、ブラウザーはどちらを使用するかを尋ねます（これを書いている時点では、これはWindows 10のEdgeのみです）、サインインしており、Webサイトに何も入力していない、ユーザー名、パスワードが送信されていないウェブサイトに、あなたのデバイスの確認だけです。
しかし、それらは非常に素晴らしいように見えますが、これらの常駐キーに関するFido Allianceによる1つの大きな見落としがありました。常駐キーを削除するには、デバイス全体をリセットする必要があります。そのため、常駐スロットがいっぱいになり、一部のキーが不要になった場合は、それに対処するか、デバイスをリセットしてどこにでも再登録する必要があります。
私の言い回しについて簡単に説明します。これらの機能を提供する物理デバイスを「デバイス」と呼びます。これらは一般的に「セキュリティキー」と呼ばれていますが、デバイスについて話すときと暗号化について明確に区別したかったためです。キーなので、「キー」は常に暗号化キーを指します。