は、hmacのパスフレーズでbcryptを改善しましたか？

Question

は、所与：

$塩 - 十分な長さの擬似ランダムに生成された文字列

$コショウ - パスフレーズが保存されているデータベースの管理者にのみ知られている十分に強力な秘密鍵、

あなたは

$ハッシュ= bcryptの（HMAC（$ userpassphrase、$コショウ）、$塩）

が

に有意義に優れて見るでしょう

$ hash = bcrypt（$ userpassphrase、$ salt）

$ pepperと$ saltを管理/保存するために余分な負担があるとしますか？

私は、hmacが結果的に$ハッシュを強く強化しないと仮定し、$ pepperを保存する負担は想定されている利点を上回っています...しかし、私は情報に基づく意見を聞きたいです。

Answer 1

鍵付きハッシュ（HMac）は、データの送信元を確認するためのものであり、パスワード保護用ではありません。たとえば、あなたと私が共有鍵を持っていた場合、計算されたhmacとともにいくつかのデータを送ることができます。そして、同じ鍵を使ってhmacハッシュが一致するかどうかを調べることができます。私は、変更されていません。

攻撃者が入手できなかった秘密のパスフレーズを効果的に隠す方法はありません。あなたがしているのは、あいまいさの層を追加することだけです。共有秘密鍵を持たないHMacを使用することは、計算が非常に簡単なSHA（$ userpassphrase、$ salt）を実行することと基本的に同じなので、パスワードハッシュスキームに意味のあるセキュリティを追加しません"パスフレーズは知られています。

bcryptの全体のポイントは、ハッシュ処理を遅くすることです。攻撃者があなたの塩のために虹のテーブルを生成するのに長い時間を要します。パスワードハッシュスキームをより安全にしたい場合は、元のハッシュ関数のコストを増やすだけです。 bcryptでは、「logRounds」（私は彼らがそれを呼んだと思います）の数を指定することができます。これは、ハッシュが実行された回数です。 logRoundsを15（10がデフォルト）と指定すると、ハッシュは2^15 = 32768回実行され、大幅に遅くなります。ハッシュを実行するのにかかる時間が長いほど、攻撃者がハッシュを破るのにかかる時間が長くなります。

Answer 2

どうやって使いたいか分かりません。チャレンジレスポンス認証を行うために$ hashを保存すると仮定すると、後で$ pepperをクライアントに渡す必要があり、それはちょうどもう一つの塩になります。単にHMACを追加するだけではあまり役に立ちません。

Answer 3

bcryptのようなパスワードストレッチ機能に余分なハッシュを付ける必要はありません。それをもう2回繰り返すほうが簡単で良いでしょう。

「コショウ」は一般的に使用されていますが疑わしい習慣です。個人的に私は、攻撃者があなたのデータベースを取得するが、秘密鍵にアクセスできない攻撃モデルは十分に考案されているため、それらに対する保護は実行される実装の複雑さに値するものではないと考えています。