私が行っていることは、実際にはパスワードをソルト処理するのではなく、それらをペパーリングすることであることがわかったディスカッションに出会い、それ以来、次のような関数で両方を実行し始めました。

hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

選択したハッシュアルゴリズムを無視します（これはソルト＆ペッパーの説明であり、特定のアルゴリズムではありませんが、安全なアルゴリズムを使用しています）、これは安全なオプションですか、それとも何か別のことをする必要がありますか？用語に不慣れな方のために：

• 塩は、通常、それが不可能なパスワードをクラックするハッシュテーブルを使用するようにするために設計されたデータベース内の文字列を格納し、ランダムに生成された値です。各パスワードには独自のソルトがあるため、パスワードを解読するためにすべて個別にブルートフォースする必要があります。ただし、ソルトはパスワードハッシュとともにデータベースに格納されるため、データベースのセキュリティが侵害されると、両方が失われます。

• 唐辛子は秘密であることが意図されている（通常は、アプリケーションのソースコードにハードコードされた）データベースとは別に格納されているサイト全体の静的な値です。これは、データベースが侵害されてもアプリケーション全体のパスワードテーブルがブルートフォース可能にならないようにするために使用されます。

不足しているものはありますか？ユーザーのセキュリティを保護するために、パスワードをソルト＆ペッパーリングするのが最良のオプションですか？この方法で行うことには、潜在的なセキュリティ上の欠陥はありますか？

注：説明のために、アプリケーションとデータベースは別々のマシンに格納されていると仮定します。パスワードは共有しないでください。したがって、データベースサーバーの違反が、アプリケーションサーバーの違反を自動的に意味するわけではありません。

OK。私はこれについて何度も何度も書く必要があるので、コショウだけで最後の標準的な回答をします。

ピーマンの見かけのアップサイド

コショウはハッシュ関数をより安全にするべきであることは非常に明白です。つまり、攻撃者がデータベースのみを取得する場合、ユーザーのパスワードは安全でなければなりません。論理的に見えますか？

だからこそ、ピーマンは良いアイデアだと信じる人がたくさんいます。それは理にかなっている"。

コショウの現実

セキュリティと暗号化の領域では、「理にかなっている」だけでは十分ではありません。安全であると見なされるには、証明可能で意味のあるものが必要です。さらに、保守可能な方法で実装できる必要があります。維持できない最も安全なシステムは安全でないと見なされます（そのセキュリティのいずれかの部分が故障すると、システム全体が崩壊するため）。

そして、ピーマンは証明可能なモデルにも維持可能なモデルにも適合しません...

コショウの理論的な問題

準備が整ったので、唐辛子のどこが悪いのか見てみましょう。

• ハッシュを別のハッシュにフィードすることは危険な場合があります。

  あなたの例では、あなたはそうしますhash_function($salt . hash_function($pepper . $password))。

  過去の経験から、1つのハッシュ結果を別のハッシュ関数に「供給する」だけで全体的なセキュリティが低下する可能性があることがわかっています。その理由は、両方のハッシュ関数が攻撃の対象になる可能性があるためです。

  そのため、PBKDF2などのアルゴリズムは、特別な演算を使用してそれらを結合します（その場合はhmac）。

  重要なことは、大したことではありませんが、ただ捨てるのは簡単なことではありません。暗号システムは、「機能するはずの」ケースを回避するように設計されており、代わりに「機能するように設計された」ケースに焦点を当てています。

  これは純粋に理論的に見えるかもしれませんが、実際にはそうではありません。たとえば、Bcryptは任意のパスワードを受け入れることができません。そのbcrypt(hash(pw), salt)ため、渡すと実際にバイナリ文字列を返すbcrypt(pw, salt)場合よりもはるかに弱いハッシュになる可能性hash()があります。

• 設計に対する取り組み

  bcrypt（およびその他のパスワードハッシュアルゴリズム）の設計方法は、saltを操作することです。コショウの概念は導入されませんでした。これは些細なことのように思えるかもしれませんが、そうではありません。その理由は、塩は秘密ではないからです。これは、攻撃者が知ることができる単なる値です。一方、ペッパーは、まさに暗号の秘密です。

  現在のパスワードハッシュアルゴリズム（bcrypt、pbkdf2など）はすべて、1つの秘密値（パスワード）のみを取り込むように設計されています。アルゴリズムに別の秘密を追加することはまったく研究されていません。

  それが安全ではないという意味ではありません。安全かどうかはわかりません。また、セキュリティと暗号化に関する一般的な推奨事項は、わからない場合はそうではないということです。

  したがって、アルゴリズムが暗号化者によって設計され、秘密の値（ペッパー）で使用できるように吟味されるまで、現在のアルゴリズムをそれらで使用することはできません。

• 複雑さはセキュリティの敵です

  信じられないかもしれませんが、複雑さはセキュリティの敵です。複雑に見えるアルゴリズムを作ることは安全かもしれませんし、そうでないかもしれません。しかし、それが安全でない可能性は非常に重要です。

コショウの重大な問題

• 維持できません

  ペッパーの実装では、ペッパーキーをローテーションする機能は使用できません。ペッパーは一方向関数への入力で使用されるため、値の存続期間中はペッパーを変更できません。これは、キーローテーションをサポートするために、いくつかの奇妙なハックを考え出す必要があることを意味します。

  これは、暗号シークレットを保存するときに必ず必要になるため、非常に重要です。キーをローテーションするメカニズムがない（定期的に、および違反の後で）ことは、セキュリティ上の大きな脆弱性です。

  そして、現在のペッパーアプローチでは、すべてのユーザーがローテーションによってパスワードを完全に無効にするか、次回のログインまでローテーションするまで待つ必要があります（これは決して行われない場合があります）...

  これは基本的に、あなたのアプローチを即座に立ち去らせます。

• あなた自身の暗号を転がす必要があります

  現在のアルゴリズムではペッパーの概念をサポートしていないため、アルゴリズムを作成するか、ペッパーをサポートする新しいアルゴリズムを発明する必要があります。そして、それがなぜ本当に悪いことなのかすぐにわからない場合は、次のようにします。

  最も無知なアマチュアから最高の暗号学者まで、誰でも彼自身が破ることができないアルゴリズムを作成できます。

  • ブルース・シュナイアー

  自分の暗号を決してロールしないでください...

より良い方法

したがって、上記で詳述したすべての問題のうち、状況を処理するには2つの方法があります。

• アルゴリズムをそのまま使用する

  bcryptまたはscryptを正しく（高コストで）使用する場合、最も弱い辞書パスワードを除くすべてが統計的に安全である必要があります。コスト5でbcryptをハッシュするための現在のレコードは、1秒あたり71,000ハッシュです。そのレートでは、6文字のランダムパスワードでも解読に数年かかります。そして、私の最小推奨コストが10であることを考慮すると、1秒あたりのハッシュが32分の1に削減されます。したがって、1秒あたり約2200ハッシュだけを話します。そのレートでは、一部の辞書のフレーズや変更でさえ安全である可能性があります。

  さらに、ドアでそれらの弱いクラスのパスワードをチェックし、それらを許可しないようにする必要があります。パスワードクラッキングがより高度になるにつれて、パスワードの品質要件も必要になります。それはまだ統計的なゲームですが、適切なストレージ技術と強力なパスワードがあれば、誰もが実質的に非常に安全でなければなりません...

• ストレージの前に出力ハッシュを暗号化する

  セキュリティレルムには、上記で述べたすべてを処理するように設計されたアルゴリズムが存在します。それはブロック暗号です。リバーシブルなので、キーをローテーションできます（そうです！保守性！）。設計通りに使用されているので良いです。それはユーザーに情報を提供しないので良いです。

  その行をもう一度見てみましょう。攻撃者があなたのアルゴリズムを知っているとしましょう（これはセキュリティに必要ですが、そうでなければ、あいまいさによるセキュリティです）。伝統的なペッパーアプローチでは、攻撃者はセンチネルパスワードを作成でき、塩と出力を知っているので、ペッパーをブルートフォースで攻撃できます。OK、それはロングショットですが、それは可能です。暗号では、攻撃者は何も取得しません。また、ソルトはランダム化されているので、歩哨のパスワードは彼/彼女を助けさえしません。したがって、残された最善の方法は、暗号化されたフォームを攻撃することです。つまり、最初に暗号化されたハッシュを攻撃して暗号化キーを回復し、次にハッシュを攻撃する必要があります。しかし、暗号の攻撃については多くの研究があるので、それに頼りたいと思います。

TL / DR

ピーマンは使わないでください。それらには多くの問題があり、2つのより良い方法があります。サーバー側のシークレットを使用しない（はい、問題ありません）と、保存する前にブロック暗号を使用して出力ハッシュを暗号化します。

コショウの正確な利点について話すべき拳：

• ペッパーは、攻撃者がデータベース（ハッシュを含む）への読み取りアクセス権を持っているが、ペッパーによるソースコードへのアクセス権を持っていない特殊な場合に、弱いパスワードを辞書攻撃から保護できます。

典型的なシナリオは、SQLインジェクション、破棄されたバックアップ、破棄されたサーバーなどです。これらの状況は、それほど一般的ではなく、多くの場合、管理下にありません（サーバーホスティング）。あなたが使うなら...

• パスワードごとに固有のソルト
• BCryptのような低速ハッシュアルゴリズム

...強力なパスワードは十分に保護されています。ソルトがわかっている場合でも、これらの条件下で強力なパスワードを総当たりにすることはほぼ不可能です。問題は、ブルートフォース辞書の一部であるか、それらの派生物である弱いパスワードです。最も一般的なパスワードのみをテストするので、辞書攻撃はそれらを非常に速く明らかにします。

第二の質問は、コショウを適用する方法ですか？

コショウを適用するためにしばしば推奨される方法は、ハッシュ関数に渡す前にパスワードとコショウを結合することです：

$pepperedPassword = hash_hmac('sha512', $password, $pepper);
$passwordHash = bcrypt($pepperedPassword);

ただし、別のより良い方法があります。

$passwordHash = bcrypt($password);
$encryptedHash = encrypt($passwordHash, $serverSideKey);

これにより、サーバー側のシークレットを追加できるだけでなく、必要に応じて$ serverSideKeyを交換することもできます。この方法にはもう少し手間がかかりますが、コードが存在する場合（ライブラリ）、それを使用しない理由はありません。

ソルトアンドペッパーのポイントは、レインボーテーブルと呼ばれる、事前に計算されたパスワードルックアップのコストを増やすことです。

一般に、単一のハッシュの衝突を見つけようとすることは困難です（ハッシュが安全であると想定）。ただし、ハッシュが短い場合、コンピュータを使用して、可能なすべてのハッシュをハードディスク上のルックアップに生成することができます。これはレインボーテーブルと呼ばれます。レインボーテーブルを作成した場合、世界に出て、あらゆる（無塩でペッパーのない）ハッシュのもっともらしいパスワードをすばやく見つけることができます。

コショウのポイントは、パスワードリストをハッキングするために必要なレインボーテーブルを一意にすることです。したがって、レインボーテーブルを作成するために攻撃者に多くの時間を費やすことになります。

ただし、ソルトのポイントは、各ユーザーのレインボーテーブルをユーザーごとに一意にすることであり、攻撃の複雑さがさらに増します。

実際、コンピューターのセキュリティのポイントは、それを（数学的に）不可能にすることではなく、数学的にも物理的にも実用的ではありません（たとえば、安全なシステムでは、単一のユーザーのパスワードを計算するために宇宙（およびそれ以上）のすべてのエントロピーを必要とします）。

セキュリティ関連性があるとハードコードされた値をソースコードに格納することはできません。あいまいさによるセキュリティです。

ハッカーがデータベースを取得した場合、ハッカーはユーザーパスワードの総当たりを開始することができます。そのハッカーがいくつかのパスワードを解読できれば、コショウがあなたのコショウを識別するのに時間がかかりません。