7

対称暗号化（ AesManagedRfc2898DeriveBytesなど）で使用するために、ユーザーが指定した文字列パスワードから暗号化キーと初期化ベクトルを安全に生成するために使用しています。

パスワードのSHA1ハッシュをsaltパラメーターとして使用していますRfc2898DeriveBytes。それは大丈夫ですか？そうでない場合は、どこから塩を入手すればよいですか？復号化するときに同じソルトが必要になりますよね？したがって、暗号化されていない場所、つまりセキュリティで保護されていない場所に保存する必要があります。安全に保管しなければならない場合は、別の「パスワード」になりますね。

void SecureDeriveKeyAndIvFromPassword(string password, int iterations, 
    int keySize, int ivSize, out byte[] key, out byte[] iv)
{
    // Generate the salt from password:

    byte[] salt = (new SHA1Managed()).ComputeHash(Encoding.UTF8.GetBytes(password));

    // Derive key and IV bytes from password:

    Rfc2898DeriveBytes derivedBytes = new Rfc2898DeriveBytes(password, salt, iterations);

    key = derivedBytes.GetBytes(keySize);
    iv = derivedBytes.GetBytes(ivSize);
}

私は定数（ハードコードされた）ソルトを使用しているのを見てきました、そして人々がそれについて不平を言っているのを見ました。パスワードからソルトを導出する方が良いと思いましたが、これが最適なソリューションかどうかはわかりません。

間もなく、暗号化する必要のあるファイルと、ユーザーが入力したパスワード文字列があります。Rfc2898DeriveBytes安全な暗号化キーとIVを導出するために適切に使用するにはどうすればよいですか？

ありがとう。

編集：

回答ありがとうございます。ソルトの主な（たぶん唯一の？）目的は、レインボーテーブルの生成を不可能にすることであることがわかりました。「P @ $$ w0rd」のハッシュは、可能なものごとに異なるハッシュを持つため、事前に生成することはできません。塩の値。私はこれを完全に理解していますが...これは本当に対称暗号化に関連していますか？ハッシュをどこにも保存していませんよね？したがって、攻撃者が考えられるすべてのパスワードの組み合わせに対応するレインボーテーブルを持っていたとしても、攻撃者は多くのことを実行できません。

したがって、私の質問は次のとおりです。対称暗号化アルゴリズム（.NETのAesManagedなど）で使用する場合、パスワードから派生した（またはハードコードされた）ソルトを使用する場合と比較して、各暗号化操作でランダムソルトを使用する利点はありますか？

4

5 に答える 5

9

ソルトはパスワードごとに一意である必要があります。つまり、ハッシュするすべてのパスワードに対してランダムなパスワードを作成します。ソルトはシークレットではなく、計算されたハッシュ値とともにプレーン テキストで保存できます。

ソルトの考え方は、攻撃者が事前に構築されたレインボー テーブルを使用してパスワードを取得できないようにすることです。彼は、パスワードごとに個別にこのようなレインボー テーブルを作成する必要がありますが、これは意味がありません。一致するものが見つかるまで、力ずくで攻撃する方が簡単です。

MSDNには、ソルトがオペレーティング システムのランダム ソースから取得される例があります。安全なソルトを取得するには、これが最善の方法です。パスワードから派生させないでください。

于 2012-09-21T11:58:23.583 に答える
4

ソルトは、ターゲットごとに異なる動作をさせることで、マルチターゲット攻撃から保護するように設計されています。レインボー テーブルは、ターゲットを取得する前に計算作業が費やされる、マルチターゲット攻撃の 1 つの具体化にすぎません。

マルチターゲット攻撃が適用される状況がありますが、レインボー テーブルは適用されません。

この一例: 一意のナンスを持つ AES-GCM など、セマンティック セキュリティを備えた認証済み暗号化スキームを使用しているとします。これで、異なるパスワードを使用して暗号化された 100 万の異なるメッセージを取得しました。

ソルトを使用しない場合、パスワードがこれらのいずれかに適用されるかどうかを確認するために、攻撃者は1 回の KDF操作と100 万回の復号化操作を必要とします。ソルトを使用する場合、攻撃者は100 万回のKDF操作と100 万回の復号化操作を必要とします。KDF は復号化に比べて遅いため、最初のスキームに対する攻撃は、2 番目のスキームに対する攻撃よりもはるかに高速です。

于 2012-09-21T13:57:52.770 に答える
3

何が何なのかよくわかりませんがRfc2898DeriveBytes、次のことは言えます: ソルトは確保する必要はありません。さて、あなたは、salt のハードコーディングされた定数値について人々が不満を言っているのを見たと言いました。Salt はランダムな値であるべきであり、定数値であってはなりません。そうしないと、その目的が無効になります。

塩が何に使われているか知っていますか？あなたは明らかにそうではありません。ハッシュをソルトとして使用することは、パスワードXが常に同じ値Yでソルトされ、その目的が無効になるため、悪い考えです。

于 2012-09-21T11:50:44.967 に答える
3

ハードコーディングされたソルトは、プロジェクトのすべての開発者 (オープンソース プロジェクトやリバース エンジニアリングの場合は一般ユーザーも) がアクセスできるため、人々は嫌います。その後、攻撃者は特定のソルトのレインボー テーブルを計算し、システムへの攻撃を開始できます。

塩分値の適切な選択は、次のようなものです。

  • パスワードを確認するたびに利用可能
  • パスワード チェック間で変更されない
  • 各 (またはほとんどの) パスワード計算で異なります

ユーザー名は、変更できない場合は適切な選択です。または、最初にユーザーを作成するときに完全にランダムな値を生成し、それをユーザー データと共にデータベースにソルトとして保存します。

于 2012-09-21T11:52:52.463 に答える
0

他の人は、塩の目的と、なぜそれが公開情報になり得るのかをすでに説明しています.

あなたの質問に対する答えの 1 つの追加部分:パスワード自体からソルトを導出しないでください。これは、Ashley Madison のハッキング後に何百万ものパスワードを公開することになったプログラミングの失敗と非常によく似ています。

問題は、パスワードを使用してソルトを生成する場合、基本的にパスワードを 2 番目の、より解読しやすい形式で使用できるようにすることです。攻撃者は PBKDF2 の出力を完全に無視し、単にソルト自体を逆にすることができます。これは、すでに壊れている SHA1 でのみ保護されています。

アシュリー マディソンでも同様のエラーが発生しました。パスワードは bcrypt を使用してメイン データベースに保存され、安全であると考えられていました。しかしその後、多くのアカウントのパスワードが実際には 2 回保存されており、2 回目のコピーは MD5 でしか保護されていないことが発見されました。

于 2015-10-26T09:19:14.170 に答える