37

許容可能な文字の範囲を使用してランダムな文字列を生成しようとしています。以下に含まれる実用的な実装がありますが、ランダムバイトを印刷可能な文字に変換するロジックがリスクにさらされているか、または誤って他の内部状態を公開しているかどうかを知りたいと思いました。使用可能な文字数を 256 で割り切れる数として保持し、生成された文字列に偏りが生じないようにしました。

using System.Security.Cryptography;
class Example {
  static readonly char[] AvailableCharacters = {
    'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 
    'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 
    'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 
    'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', 
    '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '-', '_'
  };

  internal static string GenerateIdentifier(int length) {
    char[] identifier = new char[length];
    byte[] randomData = new byte[length];

    using (RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider()) {
      rng.GetBytes(randomData);
    }

    for (int idx = 0; idx < identifier.Length; idx++) {
      int pos = randomData[idx] % AvailableCharacters.Length;
      identifier[idx] = AvailableCharacters[pos];
    }

    return new string(identifier);
  }
}

上記のサンプル コードを長さ 40 で 10 回実行すると、次の出力が得られます。

hGuFJjrr6xuuRDaOzJjaltL-ig09NNzbbvm2CyZG
BLcMF-xcKjmFr5fO-yryx8ZUSSRyXcTQcYRp4m1N
ARfPJhjENPxxAxlRaMBK-UFWllx_R4nT0glvQLXS
7r7lUVcCkxG4ddThONWkTJq0IOlHzzkqHeMi4ykU
TMwTRFORVYCLYc8iWFUbfZWG1Uk2IN35IKvGR0zX
hXNADtfnX4sjKdCgmvZUqdaXSFEr_c_mNB3HUcax
-3nvJyou8Lc-a0limUUZYRScENOoCoN9qxHMUs9Y
bQPmVvsEjx0nVyG0nArey931Duu7Pau923lZUnLp
b8DUUu6Rl0VwbH8jVTqkCifRJHCP3o5oie8rFG5J
HuxF8wcvHLpiGXedw8Jum4iacrvbgEWmypV6VTh-

私が尋ねていると思う質問は、このコードは使用するのに比較的安全ですか、それとも本当に悪い考えですか? エンド ユーザーがこの識別子を見ることはなく、寿命は非常に短いです。

追加情報

識別子の使用について詳しく説明すると、その使用目的は、あるアプリケーションから別のサードパーティ システムに情報を渡すために使用される、有効期間が短いリクエストのキーとして使用することです。データは (信頼されていない) ユーザーのブラウザーを通過する必要があるため、実際のレポート情報をデータベースに保存し、ターゲット アプリケーションがデータベースからその情報を取得して削除できるように、この識別子を生成します。

ターゲット情報は私たちの管理外のサードパーティ システムにあり (開発に関してはまだオンプレミスにあります)、サードパーティ システムに対してユーザーを直接認証することはできないため、このトークンはユーザーが識別され、データベースに保存された情報を使用してレポートが実行されます。レポート自体は、認証なしで (インターネット上で) 公開する必要があります (大部分のユーザーはサードパーティ システムにアカウントを持っていないため)。レポートは、最高の状態で保証したかった HIPAA/FERPA データを扱っているためです。攻撃者のコントロールに識別子があっても、有効なリクエストを生成できないことがわかります。

4

1 に答える 1

31

追加情報は役に立ちます。トークンを平文で送信したり、信頼できない相手に送信したりしないと思います。

実際に尋ねられた質問に答えるには: はい、コードは 240 ビットのランダム性を含む 40 文字のランダム文字列を正しく生成します。もちろん、そうするために 320 ビットのランダム性を消費することに注意してください。

おそらく、このようにして生成されるトークンの数は 2 240のごく一部であるため、攻撃者が有効なトークンを推測するのは困難です。トークンの寿命が短い場合 (トランザクションが発生している間のみトークンがデータベースに存在し、その後短時間で消える場合) はさらに良いことです。徹底した防御。

ソフトウェア RNG は、その環境からシード エントロピーとして情報を取得することに注意してください。生成を行っているマシン上でマルウェアが実行されている可能性がある場合、マルウェアはその環境を操作しようとしている可能性があり、それによってエントロピーの一部を推測している可能性があります。しかし、そのマシンでマルウェアが実行されている場合は、すでにはるかに大きな問題が発生している可能性が高くなります。

また、ガベージ コレクターは、トークンを含む文字列と配列がメモリ内に保持される期間を保証しないことにも注意してください。繰り返しますが、デバッガーを起動してメモリに問い合わせるマシンに管理者権限を持つマルウェアがある場合、キーを検出できます。もちろん、レイモンド・チェンが言うように、それは悪役がすでに密閉されたハッチウェイの反対側にいることを前提としています. 管理者権限でのマルウェアによるメモリ スキャンの心配はほとんどありません。

于 2013-10-10T15:19:24.503 に答える