チャレンジレスポンスとOATH-HOTPを使用したKeePassでのYubikey
私は今日、YubiKey 4を入手し、最初にそれをOATH-HOTP（OtpKeyProvプラグイン）でKeePassを使用することを試みました。私の構成は、ルックアヘッドカウント= 0の3つのOTPでした。ボタンを押しすぎると、OtpKeyProvプラグインが入力を認識しないことがあったため、うまく機能しませんでした。したがって、先読みカウント= 12の6つのOTPに変更しました。しかし、ボタンを6回押す必要があり、プラグインが確実に認識されるように押すまでに数秒待つ必要があったため、「快適」ではなくなりました。入力。
そこで、KeeChallengeプラグインでチャレンジ/レスポンス方式を試しました。完全に機能しました。 KeeChallengeプラグインでチャレンジ/レスポンス方式を使用することに反対することはありますか、それとも使用しても安全ですか？ OtpKeyProvプラグインがより安全であることを知っていますが、それはそれだけ違いをもたらしますか？
プラグインが内部でどのようにそれを実行するかによって、これはセキュリティを追加する非常に魅力的な方法になります。
基本的に、これはHOTPビッグタイムを誤用しますが、次に必要となる多くのOTPを計算し、それらをマスターパスと共に形成してデータベースを暗号化します。
しかし、もちろん先読みをアクティブにすると（そして特にnanoで実際にそうする必要があります）、誤ってカウンターをインクリメントした場合に備えて、キーのシーケンスがさらにいくつか生成されます。
背後にある考え方は悪くありませんが、keepassassは、シードをシード（共有シークレット）をデータベースに格納して再暗号化できるようにする必要があります。
keechallengeプラグインは同じ前提で機能します：共有シークレットを何らかのチャレンジ（HOTPのカウンター）でハッシュしますが、このプラグインは実際にはいくつかの観点から安全です。
1）log2（10 ^（6 * x））ビットの「単なる」ではなく、HMAC-SHA1の160ビット出力を提供します（xは選択した連続OTPの数、8つの連続OTPは159になり、長さの半分のビット）
簡単に言うと、同じセキュリティレベルの場合はタップ数を大幅に減らす必要があります。OTPプラグインは、より高いセキュリティのために大量のOTPを使用するように構成できますが、変更を加えると、チャレンジ/レスポンスプラグインは複数のチャレンジを実行して数を投げることもできます必要なタップの8分の1で、屋根を通り抜けるビットの数です（そして、誤ったタップと適切なシーケンスの取得の心配はありません）。
2）チャレンジはデータベースから提供されるため、誤ってキーや先読みに触れることを心配する必要はありません。つまり、複数の第2要素ソリューションを利用できるようにすることでセキュリティを低下させる必要はありません。
数字2は、Yubiにはシークレットのみがあり、DBにはチャレンジの「状態」と呼ばれるものがあることを意味しますが、TOTPでは、YubiにはDBを復号化するために必要な状態とシークレットの両方があり、状態は毎回変化しますキーに触れると、複数の州を考慮する必要があります。
ただし、共有シークレットは依然としてデータベース内に何らかの方法で格納する必要があります（チャレンジをまったく変更しない場合を除き、それは無謀です）。