ソルトハッシュ値はどこから取得する必要がありますか？

プレーンテキストで保存できないパスワードなどのハッシュ値にソルト値を追加する場合、ソルト値を取得するのに最適な場所はどこですか？コンテキストのために、これがWebページログインのパスワード用であると仮定します。

通常created TIMESTAMP、ユーザーテーブルに列があり、ユーザーがいつ登録されたかを確認できます。Saltに列を追加したくないので、タイムスタンプ列をsaltとして使用します。

SHA1(password + created)

それは重要ですか？

塩には2つの目的があります。事前にハッシュされたパスワードの大きなテーブル（「レインボーテーブル」）を使用することは実用的ではなく、ハッシュのリストでは同一のパスワードが異なって見えます。同一のパスワードの外観を変えると、複数の人が特定のパスワードを使用するという問題を回避するのに役立ちます。

したがって、発生する可能性のある塩のグループが存在しないという意味で、各アカウントには独自の塩が必要であり、塩は過度に予測可能であってはなりません。（多くのサイトが1から始まり、カウントアップされた場合、悪者は、たとえば、低塩を含むレインボーテーブルを構築できます。）それらは、一般的に予測できない以外の意味でランダムである必要はありません。それらはハッシュ自体よりも秘密ではないので、特に推測する必要はありません。

便利な方法を使用して、ソルトを生成します。アカウントの数と比較して潜在的なソルト値が多数ある場合（初期のUNIXシステムは65536の可能性があるために2バイトを頻繁に使用していました）、セミランダム割り当ては重複したソルトをほとんど提供しませんでした。

新しいパスワード（登録、パスワードリセット、パスワード更新）を保存するたびに、1つの良い方法があります。

• 新しい塩を生成する
  • 暗号的に安全な擬似乱数ジェネレータを使用する
  • 適切なサイズのソルトを使用します-適切な値は、基礎となるハッシュアルゴリズムのブロックサイズです（SHA-256の場合があります）
• 新しいパスワードトークンを生成する
  • saltをhmacキーとして使用して、基礎となるハッシュアルゴリズム（SHA-256である可能性があります）からhmac関数を作成します
  • for i in (0...65536) { password = hmac(password) }
  • hmac関数の反復アプリケーションの結果はパスワードトークンです
• saltとパスワードトークンを保存する
  • 元のパスワードを保存しないでください
  • オプションで、基礎となるハッシュアルゴリズムと検出可能性のストレッチを保存する

フレームワークを活用します。.NETではRNGCryptoServoiceProviderを使用できます...

        // If salt is not specified, generate it on the fly.
        if (saltBytes == null)
        {
            // Define min and max salt sizes.
            int minSaltSize = 4;
            int maxSaltSize = 8;

            // Generate a random number for the size of the salt.
            Random  random = new Random();
            int saltSize = random.Next(minSaltSize, maxSaltSize);

            // Allocate a byte array, which will hold the salt.
            saltBytes = new byte[saltSize];

            // Initialize a random number generator.
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

            // Fill the salt with cryptographically strong byte values.
            rng.GetNonZeroBytes(saltBytes); 
        }

他のフレームワークには、利用できる類似のクラスが必要です。ランダム性を実現するために、ソフトウェアはしばしばRandom上記のようにユーザーを採用します。定義された領域内でマウスをランダムに動かして塩を提供することは、TrueCryptで採用されているオプションです。具体的には、特定のニーズとセキュリティレベルに応じて異なります。あなたの塩は単純にできるから!@#$%です。

saltサーバー側を生成し、作成時にユーザーアカウントに割り当てます。フレームワークで利用可能な暗号生成APIを使用することをお勧めしますが、原則としてどのシーケンスでも使用できます。

通常、物は次のように保存されます。

User
-------------------
ID
Username
PasswordHashWithSalt

例：

PasswordHashWithSalt =

A15CD9652D4F4A3FB61A2A422AEAFDF0DEA4E703 j5d58k4b56s8744q

bcryptを使用して、この記事を読んでください。通常のハッシュだけでは、今日の時代では深刻な保護ではありません。

オープンソースライブラリが豊富にあり、特許も含まれていないSDRゼロナレッジパスワードプロトコルの使用を検討してください。

SDRにはソルトが必要であり、それを取得するのに最適な場所はクライアントです。キーストローク、マウスの動き、環境変数、乱数、一時フォルダー内のファイル作成時間をハッシュし、サーバーから予測できない方法で最後にソルトを作成します。SDRは、ソルト、大きな素数、ユーザーパスワードを取得し、検証キーを生成します。パスワードを保存せずにマシンから離れることはありませんが、検証キーとソルトに対応するパスワードを持っていることを確認できます。中間者や辞書攻撃の影響を受けません。念のために、データベース列のキーとソルトを暗号化します。