openssl_digest vs hash vs hash_hmac？ SALTとHMACの違いは？
openssl_digest対hash対hash_hmac
パスワードの保存にSHA512を使用したい。上記の方法のどれを使用するのが最適ですか？どうして？
SALTとHMACの違いは何ですか？
私は、HMACがハッシュ関数の上に構築されていることを読んだだけです。
SHA512+SALT+HMAC本当に必要かSHA512+SALTまたはSHA512+HMAC？
短い答え：bcrypt を使用します。
パスワードを保存する場合、実際にはパスワード自体を保存するのではなく、パスワードを検証するのに十分な「何か」だけを保存します。この「何か」は、パスワードに適用された確定的な関数の結果である必要があります。できれば、この機能を元に戻せないようにすることをお勧めします（これが、パスワード自体を保存しないという点です。サーバーのデータベースへの読み取り専用アクセスを取得した攻撃者が、すべてのユーザーのパスワードをすぐに計算するのを防ぐためです）。同じ理由で、パスワード処理機能は、パスワードの推測を不安にさせるよう努めるべきです。 「パスワード推測」は、一致が見つかるまで潜在的なパスワードを試します（これは辞書攻撃と呼ばれます）。
辞書攻撃を困難にするために、パスワード処理機能には次の3つの特性が必要です。
- slowである必要があります。
- パスワードのインスタンスごとに異なる必要があります。
- 関数を最適に計算するハードウェアは、通常の条件下でそれを実行するハードウェアとまったく同じでなければなりません。
スローネスとは、攻撃者にとって各「推測」を可能な限り高くすることです。これは通常、一方向関数を反復することによって行われます。反復回数は数千または数百万単位で数える必要があります。標準のハッシュ関数は非常に高速です。単純なPCは、SHA-256またはSHA-512ミリオン/秒の時間を評価できます。攻撃者がプレーンなPCで毎秒数百万のパスワードを試行できるようにしたくないのです。したがって、多くの反復を使用します。もちろん、これによりパスワードの検証が遅くなります-しかし、毎秒数百万のパスワードを検証する必要がないため、非常に高い反復回数を許容できます。
saltとは、インスタンスごとに関数を区別することです。 saltは、パスワードの処理を変更するパラメーターです（「パスワードと一緒にハッシュされる」としましょう）。ソルトはハッシュされたパスワードとともに保存されます。ソルトは、ユーザーがパスワードを選択するときにランダムに選択されます。ユーザーがパスワードを変更すると、新しいソルトが生成されます。ソルトの役割は、毎回異なるパスワード処理を行うことです。これは並列攻撃を防ぎます。サーバーデータベースのコピーを取得した攻撃者は、潜在的なパスワードをハッシュして1000個のアカウントを同時に攻撃し、その結果が保存されている1000個のパスワードのいずれかに一致するかどうかを確認できます。これは並行攻撃であり、ソルトはそれを打ち負かします。ハッシュされたパスワードの事前に計算されたテーブルは、特定の格納されたハッシュパスワードを簡単に検索できますが、これも一種の並列攻撃であり、ソルトは依然としてそれに対して効果的です。塩漬けはいいです。ソルトは、ソルト値が繰り返されないときに最適に機能します。十分に大きなランダムソルトは、高い確率でそれを保証します。
ハードウェアの最適性とは、攻撃者にとって攻撃を高価にすることです。私たちはサーバー（つまりPC）を使用しており、パスワードハッシュに許容できるCPUを最大限に使用しています（反復回数はそのように構成されています）。攻撃者が別の種類のハードウェア、特に [〜＃〜] gpu [〜＃〜] を使用して、よりコスト効率の高い方法で辞書攻撃を実行できる場合、このスキームは弱体化します。 500 $ GPUは通常、500 $ CPUの10倍または20倍のパスワードを試すことができます。ifパスワード処理関数は、GPUが処理する操作の種類によく対応します。上手。 SHA-256などの通常のハッシュ関数は、GPU機能に不正確にマッピングします。したがって、このような関数をパスワード処理関数の基礎として使用することにより、基本的に攻撃者に20倍の利点をもたらします。
GPUでうまく実行されない一方向関数を選択し、一方向性を損なうことなく何度も繰り返し、ソルトを追加することは、正しく行うのが非常に困難です。セキュリティは微妙なものであり、テストして保存することはできません。たくさんの暗号技術者を雇い、数か月間はその問題に取り組みます。それでも、暗号化担当者は、「私たちは何をするにしても最高でありながら、当面は弱点を見つけられませんでした」よりも決定的な答えをあなたに与えることはありません。あなたはあなた自身のスキームを発明しないように強くアドバイスされています。それがそのような問題の最初で一番のレッスンです：手作りは悪いです。
代わりに、10年間使用され、広く使用されており、まだ機能していない関数を選択してください。幸い、そのような関数が存在し、bcryptと呼ばれています。管理上の承認に過度に関係しているフィールドで作業している場合は、代わりに PBKDF2 を使用できます。ただし、PBKDF2は標準のハッシュ関数で実行されます。つまり、GPUを使用する攻撃者は、GPUに故意に敵対するbcryptにはないボーナスを取得します（詳細については、この 前の回答 を参照）。 。
[〜＃〜] hmac [〜＃〜]はそれとは何の関係もありません。これは メッセージ認証コード であり、データの整合性を検証するために使用される一種の「鍵付きチェックサム」です。 HMACはkeyを使用するため、これまでにない簡単なキー管理が必要になります。一部の人々は、このようなキー付きチェックサムをパスワード検証トークンとして保存することを提唱しています。これは、攻撃者はトークンのコピーを持っている場合でも、キーがないと役に立たないため、「パスワードを試す」ことができないという考えです。しかし、これは攻撃者がサーバーデータベースのダンプにアクセスできたとしても、キーのコピーを取得できなかったと想定しています。したがって、このモデルの実用性には疑問があります。キー管理はワームの缶です。できれば避けてください。
HMACは、ハッシュ関数（任意のハッシュ関数）で動作するものとして定義されています。いくつかの欠点がある既存のハッシュ関数でも、適切で安全なMACになるために、その関数を2回呼び出します。
私はあなたの質問が用語の定義によって最もよく答えられると思います：
- この文脈でのハッシュは 一方向関数 -つまり、引数からの結果（パスワード）を非常に簡単に見つけることができるが、引数を見つけるのが困難（または不可能）にする関数です。与えられた結果を生成します。
- salt は、ハッシュ関数の引数を補強する補助データです。これは、ハッシュされた2つのパスワードの値が同一であることを観察することにより、誤ってパスワードを発見するのを防ぐのに役立ちます。ソルトでは、保存/送信された値は、ソルトとパスワードの両方が一致する場合にのみ同一になります。
- [〜＃〜] hmac [〜＃〜] は、「メッセージ認証コード」へのハッシュ（およびオプションのソルト）の適用を指します-これは、コンテキストに応じてパスワードになる場合があります。または、少なくとも、メッセージ認証コードであるかのように、HMACにパスワードを渡すことを妨げるものは何もありません。
複数のハッシュを適用することに意味があるかどうかは非常に興味深い質問だと思います...オープンな研究の問題かもしれません。このアイデアについてのお問い合わせを投稿しました ここ 。短い要約は、同じデータに複数のハッシュ関数を適用することにはおそらくほとんど利点がないということです。ただし、ハッシュ関数が堅牢であると仮定すると、おそらく悪影響はありません（処理のオーバーヘッドを節約します）。
個人的にはソルトとハッシュ関数を使用します...そして実際のシステムでは弱いリンクになる可能性は低いので、ハッシュ関数の強さについて妄想することはありません...