BCrypt 是在 C# 中使用的一个很好的散列算法吗？我在哪里可以找到它？

Is BCrypt a good hashing algorithm to use in C#? Where can I find it?

提问by Svish

I have read that when hashing a password, many programmers recommend using the BCrypt algorithm.

我读到在对密码进行哈希处理时，许多程序员建议使用 BCrypt 算法。

I am programming in C# and is wondering if anyone knows of a good implementation for BCrypt? I found this page, but I don't really know if it is bogus or not.

我正在用 C# 编程，想知道是否有人知道 BCrypt 的良好实现？我找到了这个页面，但我真的不知道它是否是假的。

What should I be aware of when choosing a password hashing scheme? Is BCrypt a 'good' implementation?

选择密码散列方案时应该注意什么？BCrypt 是一个“好的”实现吗？

采纳答案by George Stocker

First, some terms that are important:

首先，一些重要的术语：

Hashing- The act of taking a string and producing a sequence of characters that cannot be reverted to the original string.

散列- 获取一个字符串并生成一系列无法​​恢复为原始字符串的字符的行为。

Symmetric Encryption- (Usually just referred to as 'encryption') - The act of taking a string and producing a sequence of characters that canbe decrypted to the original string through the use of the same encryption key that encrypted it.

对称加密-（通常简称为“加密”） - 获取字符串并生成一系列字符的行为，可以通过使用对其进行加密的相同加密密钥将其解密为原始字符串。

Rainbow Table- a lookup table that contains all variations of characters hashed in a specific hashing algorithm.

彩虹表- 包含在特定散列算法中散列的所有字符变体的查找表。

Salt- a known random string appended to the original string before it is hashed.

Salt- 在散列之前附加到原始字符串的已知随机字符串。

For the .NET Framework, Bcrypt does not yet have a verifiedreference implementation. This is important because there's no way to know if there are serious flaws in an existing implementation. You can get an implementation of BCrypt for .NET here. I don't know enough about cryptography to say whether it's a good or bad implementation. Cryptography is a very deep field. Do not attempt to build your own encryption algorithm. Seriously.

对于 .NET Framework，Bcrypt 还没有经过验证的参考实现。这很重要，因为无法知道现有实现中是否存在严重缺陷。您可以在此处获取 .NET的BCrypt 实现。我对密码学知之甚少，无法判断它的实现是好是坏。密码学是一个很深的领域。 不要试图构建自己的加密算法。严重地。

If you are going to implement your own password security (sigh), then you need to do several things:

如果你要实现自己的密码安全（叹气），那么你需要做几件事：

1. Use a relatively secure hash algorithm.
2. Salt each password before it's hashed.
3. Use a unique and long salt for each password, and store the salt with the password.
4. Require strong passwords.

1. 使用相对安全的散列算法。
2. 在散列之前对每个密码进行加盐。
3. 为每个密码使用唯一的长盐，并将盐与密码一起存储。
4. 需要强密码。

Unfortunately, even if you do all this, a determined hacker still could potentially figure out the passwords, it would just take him a really long time. That's your chief enemy: Time.

不幸的是，即使你做了所有这些，一个坚定的黑客仍然有可能找出密码，这只会花费他很长时间。那是你的主要敌人：时间。

The bcrypt algorithm works because it takes fiveorders of magnitude longer to hash a password than MD5; (and still much longer than AES or SHA-512). It forces the hacker to spend a lot more time to create a rainbow table to lookup your passwords, making it far less likely that your passwords will be in jeopardy of being hacked.

该bcrypt算法的工作，因为它需要5个数量级更长的时间来散比MD5密码; （并且仍然比 AES 或 SHA-512 长得多）。它迫使黑客花费更多时间来创建彩虹表来查找您的密码，从而大大降低您的密码被黑客入侵的可能性。

If you're salting and hashing your passwords, and each salt is different, then a potential hacker would have to create a rainbow table for each variation of salt, just to have a rainbow table for one salted+hashed password. That means if you have 1 million users, a hacker has to generate 1 million rainbow tables. If you're using the same salt for every user, then the hacker only has to generate 1 rainbow table to successfully hack your system.

如果您对密码进行加盐和散列处理，并且每种盐都不同，那么潜在的黑客必须为 salt 的每个变体创建一个彩虹表，只需为一个加盐+散列的密码创建一个彩虹表。这意味着如果您有 100 万用户，黑客必须生成 100 万张彩虹表。如果您为每个用户使用相同的盐，那么黑客只需生成 1 个彩虹表即可成功入侵您的系统。

If you're not salting your passwords, then all an attacker has to do is to pull up an existing Rainbow table for every implementation out there (AES, SHA-512, MD5) and just see if one matches the hash. This has already been done, an attacker does not need to calculate these Rainbow tables themselves.

如果您没有修改密码，那么攻击者所要做的就是为那里的每个实现（AES、SHA-512、MD5）提取一个现有的 Rainbow 表，然后看看是否有一个与哈希匹配。这已经完成了，攻击者不需要自己计算这些彩虹表。

Even with all this, you've got to be using good security practices. If they can successfully use another attack vector (XSS, SQL Injection, CSRF, et. al.) on your site, good password security doesn't matter. That sounds like a controversial statement, but think about it: If I can get all your user information through a SQL injection attack, or I can get your users to give me their cookies through XSS, then it doesn't matter how good your password security is.

即使有这一切，您也必须使用良好的安全实践。如果他们可以在您的站点上成功使用其他攻击媒介（XSS、SQL 注入、CSRF等），那么良好的密码安全性并不重要。这听起来像是一个有争议的说法，但想想看：如果我可以通过 SQL 注入攻击获得你所有的用户信息，或者我可以通过 XSS 让你的用户给我他们的 cookie，那么你的密码有多好并不重要安全是。

Other resources:

其他资源：

1. Jeff Atwood: .NET Encryption Simplified(great for an overview of hashing)
2. Jeff Atwood: I just logged in as you
3. Jeff Atwood: You're probably storing passwords incorrectly
4. Jeff Atwood: Speed Hashing

1. Jeff Atwood：.NET 加密简化（非常适合散列概述）
2. 杰夫阿特伍德：我刚刚以你的身份登录
3. 杰夫阿特伍德：您可能存储的密码不正确
4. Jeff Atwood：速度哈希

Note:Please recommend other good resources. I've must have read a dozen articles by dozens of authors, but few write as plainly on the subject as Jeff does. Please edit in articles as you find them.

注：请推荐其他好的资源。我一定读过几十位作者的十几篇文章，但很少有人像杰夫那样在这个主题上写得这么清楚。请在文章中找到它们进行编辑。

回答by Chris Marisic

You must not useBCrypt in .NET. You must usePBKDF2 as is with the built in .NET framework implementation. It is the only freely available cryptographically verified implementation in .NET along with being the algorithm recommended by NIST.

您不得在 .NET 中使用BCrypt。您必须将PBKDF2 与内置的 .NET 框架实现一样使用。它是 .NET 中唯一免费可用的经过加密验证的实现，同时也是NIST 推荐的算法。

StackId previously used BCrypt and moved to PBKDF2 for this very reason:

StackId 之前使用 BCrypt 并移至 PBKDF2 正是出于以下原因：

For those curious, we're hashing passwords with PBKDF2. Relavent code is here ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135), through a few layers of indirection. In an earlier iteration, we were using BCrypt; but moved to PBKDF2 as it is built into the .NET framework, whereas BCrypt would require us to verify an implementation (no small undertaking).

对于那些好奇的人，我们正在使用 PBKDF2 散列密码。相关代码在这里（ http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135），通过几个间接层。在早期的迭代中，我们使用了 BCrypt；但转移到 PBKDF2，因为它内置于 .NET 框架中，而 BCrypt 需要我们验证实现（不小的任务）。

Kevin Montrose, May 27 2011

凯文·蒙特罗斯，2011 年 5 月 27 日

(Updated link on GitHub)

（GitHub 上的更新链接）

Edit:The meaning of verifiedin cryptographic terms seems to not be readily understood, a verified implementation means it's been cryptographically proven to be implemented without error. The cost of this can easily reach $20,000 or higher. I recall this when I was doing research on OpenSSL and read where they stated they haven't completed the entire verification process but if you need fully verified that they can point you down the right path for it and mentioned costs associated. Certain government requirements include mandates for verified encryption algorithms.

编辑：在加密术语中验证的含义似乎不容易理解，经过验证的实现意味着它已被加密证明可以正确实现。这样做的成本很容易达到 20,000 美元或更高。我记得当我对 OpenSSL 进行研究并阅读他们声明他们尚未完成整个验证过程的地方时，但如果您需要完全验证他们可以为您指明正确的路径并提到相关成本。某些政府要求包括对经过验证的加密算法的要求。

The bcrypt implementations in .NET have not been verified. Using an unverified encryption implementation you can't be absolutely certain that there is not either intentional malicious faults in it such as allowing a backdoor into what is encrypted or unintentional implementation faults that result in cryptographically insecure data.

.NET 中的 bcrypt 实现尚未经过验证。使用未经验证的加密实现，您不能绝对确定其中不存在故意的恶意错误，例如允许后门进入加密内容或导致加密不安全数据的无意实现错误。

2014 edit:For anyone that questioned the imperativeness of using verified cryptopgraphical algorithims look at the devastation that was wrought by the heartbleed hackexploited in OpenSSL. That is the cost of using an unverified implementation. It's secure.... until you find out that any person can just read the entire memory contents of your server.

2014 年编辑：对于任何质疑使用经过验证的加密算法的必要性的人，请看看OpenSSL 中利用的Heartbleed hack造成的破坏。这是使用未经验证的实现的成本。它是安全的......直到您发现任何人都可以读取您服务器的整个内存内容。

The author of the change which introduced Heartbleed, Robin Seggelmann, stated that he "missed validating a variable containing a length" and denied any intention to submit a flawed implementation. Following Heartbleed's disclosure, Seggelmann suggested focusing on the second aspect, stating that OpenSSL is not reviewed by enough people.

引入 Heartbleed 的更改的作者 Robin Seggelmann 表示，他“错过了对包含长度的变量的验证”，并且否认了提交有缺陷的实现的任何意图。在 Heartbleed 的披露之后，Seggelmann 建议将重点放在第二个方面，指出 OpenSSL 没有得到足够多的人的审查。

This is the definition of an unverified implementation. Even the smallest defect can result in crippling the entire security.

这是未验证实现的定义。即使是最小的缺陷也可能导致整个安全性的瘫痪。

2015 edit:Removed recommendation based language and replaced with absolutes. Embedded original Kevin Montrose comment for posterity.

2015 年编辑：删除了基于推荐的语言并替换为绝对语言。为后代嵌入原始的凯文蒙特罗斯评论。