使用RNGCryptoServiceProvider生成随机字符串

Question

使用RNGCryptoServiceProvider生成随机字符串

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数据，我们希望尽可能确保即使在攻击者控制下，他们也无法生成有效的请求。

- Joshua

2

这个问题没有足够的信息来回答。你在描述一个安全系统，但没有描述它所保护的攻击！不要让我们批评你的锁，而不告诉我们门后面有什么和谁试图破坏它。 - Eric Lippert

1

@ts GUIDs保证唯一性，而不是随机性。第四版GUID不需要具备加密强度的随机性。 - Eric Lippert

3

@TS：再次强调，GUID并不保证是不可预测的，它们只保证是唯一的。Joshua需要一个强有力的不可预测性保证。 - Eric Lippert

1

你的字符集非常接近于Base64（它使用+和/，而你使用-和_），将生成的字节数组进行Base64编码是否也可以解决问题？ - Scott Chamberlain

1

如果您没有一个可以均匀地将256分割的字符集，您可以查看https://dev59.com/3XVD5IYBdhLWcg3wNIrc#19068116，它假设从取`2^64 mod chars.Length`导致可忽略的偏差。 - CodesInChaos

显示剩余4条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Eric Lippert · Accepted Answer

附加信息很有帮助。我假设您从未以明文形式发送令牌，也从未将其发送给不受信任的方。

回答实际问题的是：是的，您的代码正确生成了一个包含240位随机性的40个字符的随机字符串。我注意到您消耗了320位的随机性来完成这项工作，但无论如何，位很便宜。

假设因此生成的令牌数量是2²⁴⁰的非常小的一部分，因此攻击者难以猜测有效的令牌。如果令牌寿命很短-如果它们只在交易发生时存在于数据库中，然后在短时间内消失-那就更好了。深度防御。

请注意，软件RNG将种子熵从其环境中获取。如果可以在执行生成操作的计算机上运行恶意软件，则可能尝试操作该环境，并由此推断出部分熵。但如果您在该计算机上运行恶意软件，则很可能已经面临更大的问题。

我还注意到，垃圾收集器不能保证包含令牌的那些字符串和数组在内存中停留的时间有多长。同样，如果您在计算机上具有管理员权限的恶意软件启动调试器并查询内存，则可以发现键。当然，这预设了坏行为者已经处于密闭舱口错误的一侧，如Raymond Chen所说。带有管理员权限的恶意软件进行内存扫描是您最不用担心的问题之一！