与えられた：
$salt - 疑似ランダムに生成された十分な長さの文字列
$pepper - パスフレーズが保存されているデータベースの管理者のみが知っている、十分に強力な秘密鍵
見えますか
$hash = bcrypt(hmac($userpassphrase,$pepper),$salt)
～より有意義に優れている
$hash = bcrypt($userpassphrase,$salt)
$salt と同様に $pepper を管理/保管するという余分な負担を考えると?
私の仮定では、hmac は結果として得られる $hash を有意に強化せず、$pepper を格納する負担は想定される利点を上回ります...しかし、情報に基づいた意見を聞きたいです。
鍵付きハッシュ (HMac) は、データのソースを検証するためのものであり、パスワード保護のためのものではありません。たとえば、あなたと私が共有キーを持っている場合、計算された hmac と一緒にデータを送信できます。同じキーを使用して、hmac ハッシュが一致するかどうかを確認できます。一致する場合、データがどこから来たかがわかります私、変更されていません。
攻撃者がアクセスできない秘密のパスフレーズをマシン上に効果的に隠す方法はありません。あなたがしていることは、あいまいなレイヤーを追加することだけです。共有秘密鍵を持たずに HMac を使用することは、計算が非常に簡単な SHA($userpassphrase, $salt) を行うことと本質的に同じです。 " パスフレーズはわかっています。
bcrypt の全体的なポイントは、ハッシュ プロセスを遅くすることです。そのため、攻撃者がソルトのレインボー テーブルを生成するのに長い時間がかかります。パスワード ハッシュ スキームをより安全にしたい場合は、元のハッシュ関数のコストを増やすだけです。bcryptでは、ハッシュが実行される回数である「logRounds」（彼らがそれを呼んだと思います）の数を指定できます。logRounds を 15 (デフォルトは 10) に指定すると、ハッシュは 2^15 = 32768 回実行され、大幅に遅くなります。ハッシュの実行に時間がかかるほど、攻撃者がハッシュを破るのに時間がかかります。
どのように使用したいかわかりません。後でチャレンジ/レスポンス認証を行うために $hash を保存すると仮定すると、クライアントに $pepper を取得する必要があり、それは単なる別のソルトになります。HMAC を追加するだけではあまり役に立ちません。
bcrypt のようなパスワード拡張機能に追加のハッシュを追加しても意味がありません。あと数回繰り返す方が簡単で良いでしょう。
「コショウ」は一般的に使用されていますが、疑わしい慣行です。個人的には、攻撃者がデータベースを取得するが、秘密鍵にアクセスしない攻撃モデルは十分に考案されているため、それらから保護することは、結果として生じる実装の複雑さに見合わないと考えています。