Question

过去我见过人们说use a guid，我相信我已经看过一次了。

然后在this question中并在编写问题之前进行搜索，看来GUID不应该用于与安全相关的任何事情。所以我的问题是，如何将随机的64位数字作为重置密钥或登录密钥？我被建议做以下但我听说当使用RNG时，如果两个核心同时进行，它将具有相同的种子，因此不安全。我应该使用带有锁（rng）{}的静态函数和下面的代码并调用它吗？还有另外一种方法吗？我该怎么做？

using (var rng = new System.Security.Cryptography.RNGCryptoServiceProvider())
{
    byte[] inBytes = new byte[4];
    rng.GetBytes(inBytes);
    return BitConverter.ToInt64(inBytes,0);
}

Answer 1

安全的关键不一定在关键。如果生成一个足够长度的随机密钥，并将该密钥存储在数据库中并且有一个到期日期，那么您的解决方案应该足够安全。只是生成一个安全的哈希对我的口味来说不够安全，但是如果密钥必须在我的数据库中，那么当我找回一个时我就会有信心。

为什么到期日？不一定是为了增加安全性，而是因为它们通常用于立即使用。如果用户在一天内没有使用密码重置密钥，我想让它过期并让他们要求另一个。重置消息在某处，如果它在网络空间（可能在别人的邮箱中）徘徊，最好限制它的生命周期。

“信心”是什么意思？简单地说：密钥是我生成的密钥的概率很高。如果密钥只是内部一致（安全散列），那么如果有人偶然发现我生成密钥的方法，那么他们就可以生成假密钥。当然，如果我使用私有加密密钥生成哈希，他们需要找到我的私钥。但如果他们这样做了，那么我的数据库就会曝光。

另一方面，如果我生成一个大的随机密钥并将其存储在我的数据库中，那么有人打破系统的唯一方法就是猜测数据库中的密钥。如果我使它们过期，并且一旦使用它们就会使它们失效，那么一个足够大的密钥使这不太可能。如果你添加一些糟糕的猜测安全性，比如在几次错误的猜测之后重定向远离后门页面，那么你就会让某人猜测重置或后门密钥非常困难。有了这个，我“自信”我的授权成功后门尝试，我可以在我的应用程序中使用该算法。

我们在大型付款流程应用程序中执行此操作。我们和客户对提供的安全性非常满意。

如何安全地制作重置密钥和登录令牌？

1 个答案: