我的密码存储技术是否足够强大

Question

这是一个关于我的安全流程是否适合我存储的信息类型的问题。

我正在使用带有 SQL 后端的 ASP.NET 4.0 构建一个网站，并且需要知道我的安全性在密码和哈希值等方面的表现如何。

我不存储任何关于某人的重要信息 - 没有 real names, addresses, credit card 详细信息或类似的东西......只是 email and username。

目前，我故意省略了一些细节，因为我不确定告诉你它们是否会削弱我的安全性，但如果不是，我可以稍微透露更多信息。

这是我的做法：

1. 用户使用他们的电子邮件和唯一的用户名进行注册，最高可达50 charslong
2. 他们创建密码（最少6 chars) 使用键盘上的任何字符（我对输入进行HTMLEncode 并使用parameterized 存储过程，所以我不限制字符）
3. 我向他们发送了一封电子邮件，其中包含一个链接以验证他们是真实的。
4. 我使用 FormsAuthentication 来设置身份验证 cookie，但我目前没有使用 SSL...我了解通过普通 http 发送身份验证详细信息的含义，但我已要求我的主机添加证书所以它应该很快就准备好了。

这是我需要确定的哈希位！

我从以下字符集中创建了一个随机的 100 字符盐（我只使用 System.Random 类，什么都没有cryptographic） - abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNOPQRSTUVWXYZ0123456789!£$%^*()_{}[]@~#<,>.?

然后将其与密码合并，然后使用 SHA-512 (SHA512Managed class) 散列数万次（需要将近 2 seconds on my i7 laptop 来生成最终散列）。

这个最终的哈希然后被转换为base64 字符串，并与数据库中已经哈希的密码进行比较（盐也存储在数据库的另一列中）

几个问题（暂时忽略SSL的缺失，我只是还没有购买证书，但它会在一周左右准备好）：

1. 您觉得这是否足够安全？我知道存在一定程度的安全性，只要有足够的时间和资源，任何东西都可能被破坏，但鉴于我不存储关键数据，这似乎足够了吗？

2. 透露我对密码进行哈希处理的实际次数会削弱我的安全性吗？

3. 100 字符盐与 20 字符 1 相比有什么不同吗？
4. 通过透露我如何将密码和 salt 连接在一起，这会削弱我的安全性吗？

Answer 1

1. 理论上，您的哈希方案听起来不错。实际上，听起来你有rolled your own crypto，这很糟糕。使用bcrypt、scrypt 或pbkdf2。所有这些都是由安全专业人员设计的。
2. 不是真的，但我认为无论如何都不需要任何人知道。
3. 没有。它只需要对每个用户都是独一无二的。 salt 的目的是防止预先计算哈希/彩虹表攻击。
4. 一旦您使用 bcrypt（或 scrypt 或 pbkdf2），这将不适用

http://security.stackexchange.com 有一些关于这个主题的主题，你应该去看看。

一些额外的注意事项 - 严重的攻击者会比您的笔记本电脑更快地破解 sha512 哈希。例如，您可以从 Amazon 或类似网站租用带有几个 Tesla GPU 的服务器，然后以每秒数十亿哈希的速度开始破解。 Scrypt 努力通过使用内存密集型操作来防止这种情况发生。

密码最少 6 个字符是不够的，至少要 8 个。一个相关的图像，我没有验证时间，但它给出了一个粗略的估计并给你一个大致的想法（不包括字典攻击，它可以针对更长的时间密码）：

Answer 2

那么，让我们试着一一回答你的问题：

你觉得这足够安全吗？我知道存在一定程度的安全性，只要有足够的时间和资源，任何东西都可能被破坏，但鉴于我不存储关键数据，这似乎足够了吗？

没有。它肯定不够“安全”。

没有看到代码，很难说更多。但是，您直接使用SHA512 而不是使用 HMAC，这一事实表明存在一个问题。不是因为您需要使用 HMAC，而是因为大多数为此目的而设计的算法都在后台使用 HMAC（出于多种原因）。

而且您似乎正在做hash = SHA512(hash)（仅从您的措辞来看），这被证明是不好的。

所以没有看到代码，很难确定，但它没有指向正确的方向......

透露我对密码进行哈希处理的实际次数会削弱我的安全性吗？

不，不应该。如果是这样，则说明算法的其他地方有问题。

100 个字符的盐与 20 个字符的盐有什么区别吗？

不。 salt所做的只是使哈希值唯一（迫使攻击者分别攻击每个密码）。你所需要的只是一种足够长的盐，在统计上是独一无二的。感谢Birthday Problem，128 位对于 1/10^12 的碰撞机会已经绰绰有余。这对我们来说已经足够了。所以这意味着 16 个字符是盐效力的上限。

这并不意味着使用更长的盐不好。这只是意味着使其长度超过 16 个字符并不会显着提高它提供的安全性...

通过透露我如何将密码和盐结合在一起，这会削弱我的安全性吗？

如果是这样，则您的算法存在严重缺陷。如果是，则等于Security Through Obscurity。

真正的答案

这里真正的答案是不要重新发明轮子。像 PBKDF2 和 BCRYPT 这样的算法正是为了这个目的而存在的。所以使用它们。

更多信息（请注意，这些都是关于 PHP，但这些概念 100% 适用于 ASP.NET 和 C#）：

• YouTube Video - Password Storage and Hacking in PHP
• Blog Post - The Rainbow Table Is Dead
• Blog Post - Properly Salting Passwords
• PHP password_hash RFC
• Blog Post - Seven Ways To Screw Up BCrypt