現在、私は KeePassXC を比較的強力なマスターパスワードとともに使用しています。セキュリティをさらに向上させるために、YubiKeyを購入して2要素認証を行うことを考えました。
KeePassXCは、いわゆる「HMAC-SHA1チャレンジレスポンスモード」をサポートしています。
KeePassXCでFAQ彼らは言う:
KeePassXCはYubiKeysによる2要素認証(2FA)をサポートしていますか?
はいといいえ。 KeePassXCはデータベースを保護するためのYubiKeysをサポートしていますが、厳密に言えば、2要素認証ではありません。 KeePassXCはチャレンジを生成し、このチャレンジに対するYubiKeyの応答を使用してデータベースの暗号化キーを強化します。つまり、ある意味でパスワードは強力になりますが、データベースを復号化しようとするたびに期待される応答が変わるわけではないため、技術的には別の第2要素とは見なされません。ただし、データベースを保存するたびに変更されます。
攻撃者が私のKeePassXCデータベースにアクセスでき、おそらくシステムにキーロガーをインストールしているとすれば、この場合、追加のYubiKeyは役に立たないのですが、私はここにいますか?
では、強力なマスターパスワードを既に使用している場合、KeePassXCのハードウェアセキュリティキーを使用するのは妥当でしょうか。
適切に設計されたパスワードマネージャは、セキュリティのために認証に依存しません。代わりに、暗号化に依存しています。そのため、パスワードマネージャーデータベースのロックを解除しても、単一要素認証は必要なく、多要素認証ははるかに少なくなります。
これが意味することは、認証プロセスを強化するために通常使用される種類のものが(そして、YubiKeyはその点で非常に優れています)、セキュリティがローカルまたはエンドツーエンドに主に基づいているものになると、本質的に異なる役割を果たします暗号化。アプローチは大きく3つありますが、それぞれの詳細です。
場合によっては、明らかな2番目の要素は純粋なセキュリティシアターです。ユーザーにとって2FAのように見えることを行うことは可能ですが、心配する必要のある攻撃者には簡単に回避できます。私たちは(私が働いている1Passwordで)、何年にもわたって顧客からの強いプレッシャーに抵抗してきました。
このオプションは無視してください。ユーザーが最終的に弱いマスターパスワードを使用したり、マスターパスワードを保護しなかったりして、他の方法で保護する可能性がある場合、それは何の役にも立ちません。つまり、人々がパスワードマネージャーのセキュリティの弱点を弱めると、劇場2FAによって保護されていると感じるため、効果的なセキュリティが非常に弱まります。
多くのパスワードマネージャーはオフラインで使用できますが、リモートサービスへの認証は必要ありませんが、新しいデバイスをセットアップして(少なくとも)データ同期を機能させるには、通常、認証コンポーネントが必要です。 2FAは、ユーザーのセキュリティのマイナーな部分ですが、その認証コンポーネントに追加できます。
ちなみに、これは1Passwordで行うことです。 2FAを有効にする場合、新しいデバイスを設定するときに必要です。これに制限することで、ユーザーが弱いマスターパスワードで逃げることができる、またはローカルで暗号化されたデータを取得する攻撃者から2FAが魔法のようにユーザーを保護することをユーザーに信じさせないことが期待されます。
データの暗号化解除にはキーが必要であり、そのキーを取得するにはユーザーが保持するシークレット(通常はマスターパスワードなど)が必要です。ここでの難点は、鍵導出関数(KDF)が確定的でなければならないことです(毎回同じ鍵を導出する必要があるため)。
しかし、ユビキーのようなものの美しさは、それを明らかにすることなく秘密の知識を証明できることです。これらはチャレンジ/レスポンス方式で機能するように設計されており、各チャレンジはランダム化され、毎回ユニークな応答になります。しかし、それぞれの正しい応答は秘密の知識を証明します。これが、認証コンテキストでこれらのことを本当によくするものです。しかし、これは鍵の導出中には役に立ちません。
したがって、Yubikeyが静的な秘密を吐き出すことは、最も重要なセキュリティ機能をあきらめるモードでデバイスを操作することです。それは可能です(Keepassが明らかにそれを使用しており、一部のユーザーは同様のことをジェリーで仕掛けているためです)が、Yubikeyが通常行うセキュリティ保証は実際には提供されていません。
これは純粋なセキュリティシアターではありませんが(実際の利益はあります)、ユーザーがセキュリティゲインを過大評価し、セキュリティのより強力な部分(マスターパスワード)を弱める可能性があります。
元の質問に戻ります。 (3)に記載されているようにユビキーを使用することは理にかなっていますか?それが何をして何から保護されていないかを理解している限り(そして、これらはYubikeyが通常あなたを保護しているものとは異なります)、それを使用することは不合理ではありません。
ただし、1Passwordでは、セキュリティの利点はセキュリティプロパティに関する人々の誤解から生じるセキュリティの脅威に見合うものではないため、パスワードマネージャーが(3)を奨励することは賢明ではないと考えています。しかし、私は非常にこの種のことに対する顧客のプレッシャーを理解しています。また、合理的な人々が異なる結論に至る可能性があることも理解しています。
この場合のYubikeyはMFAではありません。チャレンジ/レスポンスモードでは、CR出力に加えてパスコードを使用する必要がないためです。このため、ユビキーはユーザーが誤ってトークンの側面をノックしてテキストフィールドに意味不明な文字を入力することがよくあります。このモードで動作するYubikeyは、パスワードを出力するための自動キーボードにすぎません。
ここで興味深いのは、データベースが保存されている場合を除いて、データベースシステムKeePassXCが実際にYubikeyに対するチャレンジを更新していないことです。したがって、データベースが変更なしで時々読み込まれるだけの場合、予想される課題は変更されません。これは、認証システムが新しい応答を要求していないため、Yubikeyが同じ応答値を返すことを意味します。アプリケーションについての私の限られた理解では、これはKeePassXCが変更できる制限ですが、何らかの理由で変更されていません。
チャレンジ/レスポンスモードのYubico情報:
https://www.yubico.com/products/services-software/personalization-tools/challenge-response/
つまり、KeePassXCデータベースを実行するたびに保存することに専念すれば、キーロガーを使用していても、Yubikeyの使用を信頼できます。このシナリオでは、データベースは復号化されるたびに新しい応答を期待し、以前の応答は機能しません。ただし、これはユーザーとしてのあなたの側の高い注意力を必要とし、長期間にわたって望ましくない場合があります。
攻撃者が私のKeePassXCデータベースにアクセスでき、おそらくシステムにキーロガーをインストールしているとすれば、この場合、追加のYubiKeyは役に立たないのですが、私はここにいますか?
はい、しかしあなたが考えている理由ではないかもしれません。攻撃者がシステム上でマルウェアを実行している場合、必要な要素の数に関係なく、データベースのロックを解除した瞬間にパスワードが侵害されると想定する必要があります。今日のほとんどの「キーロガー」は、単純なキーロギングよりもはるかに多くのことをしています。
すべてのマルウェアがキーストロークのログを記録している場合でも(ログ記録にyubikey入力が含まれていると想定した場合)、攻撃者に必要なのは、KeePassデータベース、パスワード、およびそのデータベースインスタンスに対応するHMAC-SHA1応答だけです。 KeePassXCがロックを解除するたびに新しいチャレンジでデータベースを再書き込みすることを決定した場合でも、これは実際には何も変更せず、攻撃者はすべて3を取得できます。
はい、それは合理的です(いくつかの追加の仮定の下で)。
(上記で説明したように)ローカルマルウェアに対して実行できることはほとんどありませんが、他にも注意すべき攻撃ベクトルがあります。
ラップトップを使用するすべての場所で、ロック解除パスワードが周囲のカメラに漏洩することに注意してください。
物理ハードウェアキーを使用すると、もう1つのセキュリティ層があります。ラップトップとハードウェアキーは通常一緒に移動して差し押さえられるため、これは、ハードウェアキー自体が保護されている(誰も接続して使用できない)場合にのみ意味があります。