ユーザー認証に2つのソルトを使用していますか？
データベースにユーザーの資格情報を保存する場合、パスワードのハッシュ化は最低限必要なことであることがわかっていますが、ハッシュ化する前にソルト化することをお勧めします。ソルトは、ランダムに生成され、十分な長さで、ユーザーごとに一意である必要があります。
two salt（十分な長さとランダムに生成されたものの両方）の使用に関する記事をどこかで読んだことを覚えています（ただし、どこにいるかは覚えていません）。
- 1つのグローバルな塩
- エントリーごとに1つのユニークな塩
結果のハッシュは次のようになります：hash(globalSalt + password + uniqueSalt)（連結の順序は本当に重要ではありません）。
エントリごとに1つの一意のソルトを持つよりも安全な理由はありますか？攻撃者は、グローバルソルトが保存されているコードファイルにアクセスできると想定しています。
私は答えを書いてから、もう少し読んで、私の答えを部分的に編集しました。この質問はすでにStack Overflowで議論されています。 この質問で受け入れられた答え は良い出発点です。リンクをたどってください。
私の意見は：
静的ソルト（グローバルと呼びます）は、次の理由でいくらか価値があります：
- 実装は簡単で、実行時にデータベースのルックアップを必要としません。つまり、簡単に拡張できます。
- このソルトは静的であり、アプリケーションコードにグローバル定数として保存するか、INIファイルから読み取ることができます。データベースへのアクセスを取得するこの方法（SQLインジェクション攻撃など）が必ずしもこの塩を明らかにするわけではありません。
パスワードごとのソルトは重要です：
- これは、各パスワードに固有のランダムな文字列で、サーバー側で生成され、データベースにプレーンテキストで保存されます。 N個のパスワードの場合、これにより Rainbow table attach N x Nの合計検索スペースが効果的になります。これは、データセットのサイズが大きいため、事前に計算されたRainbowテーブルによって効果的に攻撃することはできません。
Stack Overflowの議論から学んだもう1つの便利なヒントは、可能であればusernameを暗号化することです。私は実際にはそれを考えていませんでしたが、特定のシナリオではもちろん理にかなっています。
編集：すばらしい記事を読んでください 「レインボーテーブルで十分：安全なパスワードスキームについて知っておくべきこと」 。パスワードのハッシュについて言われていることのほとんどは、よく使われている「ソルト付きMD5/SHA256」アプローチ全体を含めて間違っています。
これは、StackOverflowですでにほとんど尋ねられています： パスワードをハッシュするためのダブルソルト？
この質問を読んだところ、1年ほど前にSOに投稿した質問を思い出しました： ハッシュソルトに関する包括的な情報 。ハッシュについてもう少し学ぶことに興味がある人にとって非常に役立つ他の情報があるので、質問と回答を読むことに興味があるかもしれません。
また、一般にユーザー認証を実装することは、回避できるのであれば、実際に自分で取り組むことではないことに注意してください。常に覚えておいてください 車輪についてさらに学ぶことを計画しない限り、車輪を再発明しないでください 。