在存储到数据库之前保护密码
我正在使用本文中提供的 ASP.NET 密码哈希代码示例。它使用 32 字节 RNGCryptoServiceProvider 实例进行 Salt 处理，并使用 SHA256Managed 实例进行哈希处理。
- 您是否发现此处描述的方法在生产环境中使用有任何问题？
- 我不明白 BytesToHex 方法需要什么，也不明白为什么在那里附加“x2”。有什么想法吗？
- 如果我想在 SQL Server 数据库中存储这个哈希密码（由 HashPassword 方法返回），应该使用什么数据类型。 CHAR(128)、VARCHAR(128) 或其他方法，每种方法都有优缺点。
TIA
I am using the ASP.NET password hashing code example provided in this article. Its using 32 bytes RNGCryptoServiceProvider instance for Salt and SHA256Managed instance for hashing.
- Do you see any issues with the approach described here to be used in production environment.
- I don't understand what is the need of BytesToHex method and also why "x2" is appended there. Any ideas?
- If i want to store this hashed password (retunred by HashPassword method) in SQL Server database, what data type should be used. A CHAR(128), VARCHAR(128) or something else with pros and cons of each approach.
TIA
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如图所示，实现并没有任何真正的错误。这里真正的难题不一定是正确地散列事物，也不一定是正确地管理帐户，这样就不会出现任何漏洞。无论如何，您可能在大多数情况下使用内置的成员资格提供程序 - 通常没有充分的理由推出您自己的。
.NET 加密内容处理字节，大多数其他系统都会输出这些字节的十六进制表示形式 - 请查看 PHP 示例。 BytesToHex 方法的工作就是进行这种转换。在 ToString 方法中使用“x2”告诉字节要使用什么格式——在本例中是十六进制。 ，请参阅文档。
首先参见#1。就我个人而言，如果我自己进行操作，我会使用 VARBINARY 或 BINARY 而不会进行文本转换——这是一个浪费的步骤，因为 .NET 无论如何都希望将其视为 byte[]。如果您想要文本，并且您确定从未更改编码或散列方法，那么我想 CHAR(LENGTH_OF_HASH) 将是最有效的存储选项。
There isn't anything really wrong with the implementation as shown. And the real hard problems here aren't necessarily properly hashing things as properly managing accounts so there isn't a hole somewhere. In any case you probably using the built-in membership providers for most cases -- there typically isn't a good reason to roll your own.
The .NET crypto stuff handles bytes, and most other systems spit out hexidecimal representations of these bytes -- look at the PHP examples. The BytesToHex method's job is to make this conversion. Using the "x2" in the ToString method tells the bytes what format to use -- in this case Hexidecimal. See the documentation for a deeper explanation.
See #1 first. Personally, if I was rolling my own, I would use a VARBINARY or BINARY and not make the text conversion -- it is a wasted step as .NET wants to treat it as a byte[] anyhow. If you want text, and you were sure you were never changing your encoding or hashing method, then I guess CHAR(LENGTH_OF_HASH) would be the most efficient storage option.
好的，首先我们来谈谈哈希。首先你应该知道，当人们使用通用密码时，简单的哈希（盐+密码）很容易被破解。因此，在他们破解大部分用户密码之前，仅加盐哈希通常不会为您赢得太多时间。
场景：假设您需要 24 小时才能注意到发生了违规行为。在这个短暂的窗口内，许多帐户已经受到损害。您重置了所有用户帐户密码，用户现在安全了吧？因此，您向所有用户发送电子邮件，通知他们违规行为并建议他们重置密码。问题是那些愚蠢的用户已经在互联网上使用该密码一段时间了，他们的银行、电子邮件等都使用相同的密码。因此，即使您阻止他们使用被盗的密码访问您的网站，用户也可能拥有其他帐户，他们必须这样做重置。假设他们又需要一天时间才能收到电子邮件并重置密码。如何为用户争取更多的时间？
答案是PBKDF2。这给哈希增加了大量的复杂性，因此每个密码的每次测试所花费的时间比简单的加盐哈希长数千倍。要在 .NET 中完成此操作，请使用 Rfc2898DeriveBytes 类。请阅读以下内容查看工作示例：“如何存储加盐密码哈希的另一个示例”。
我想不出任何理由。
实际上，原始字节效果最好，如果您想将其存储为文本，Base64 也值得考虑。
Ok first let's talk about the hashing. First you should know simple Hash(Salt+Password) can be cracked easily enough when people use common passwords. So a salted hash alone generally doesn't buy you much time before they've cracked a large percentage of you're user's passwords.
Scenario: Let's say it takes you 24 hours to notice a breach was made. Many accounts will already be compromised in this short window. You reset all user account passwords, the users are safe now right? So you send emails to all your users informing them of the breach and advising them to reset their password. The trouble is those silly users have been using that password around the internet for some time, the same password for their bank, email, etc. So even after you stop them accessing your site with the stolen passwords the user may have other accounts they must reset. So let's say it takes another day for them to receive the email and reset their passwords. How do you buy more time for user?
The answer is PBKDF2. This adds a large volume of complexity to the hash so that each test of each password takes thousands of times longer than a simple salted hash. To accomplish this in .NET one uses the Rfc2898DeriveBytes class. See a working example by reading: "Another example of how to store a salted password hash".
No reason I can think of.
Acutally raw bytes works best, Base64 is also worth considering if you want to store it as text.