bcrypt/Bcrypt.net的强度和替代方案

Question

经过大量的研究，我决定在我的Phonegap应用程序中使用bcrypt（欢迎评论）来哈希和存储密码。

几天前，我偶然发现了Bcrypt.net，并且它对我来说似乎“足够好”（同样，请随意评论）。那么，C#中还有哪些其他可替代的bcrypt实现？ Bcrypt.net的实现中是否存在任何严重缺陷？

我的安全模型基本上是这样的：

1. 用户在客户端输入他的 PIN / 密码 / 密语
2. 通过安全的SSL将此发送到我的 .net 应用程序（因此基本上是以明文形式从客户端发送）
3. 使用像bcrypt.net这样的库来哈希密码并进行存储/比较

在这里还有我真正需要考虑的其他事情吗？

非常感谢您的帮助。

- reggaemahn

Answer 1

很高兴看到有人做了一些研究。

我没有看到任何不使用bcrypt的好理由。通常，在服务器上使用bcrypt、PBKDF2或scrypt提供一个良好的安全层。

一如既往，魔鬼在细节中。你当然需要SSL，如果可能的话，使用AES加密的TLS 1.2。如果你不能做到这一点，请确保在连接中除了用户名/密码+必要的HTML之外，不要允许其他任何东西。

你应该决定密码的字符编码。我建议使用UTF-8，可能缩小到可打印的ASCII字符范围内。要么记录所使用的字符编码，要么将其存储在配置文件中。

尝试连同“哈希”密码一起存储所有输入参数到bcrypt。当用户以后输入他/她的密码时，这样做使升级到更高的迭代次数更容易。你需要生成一个安全的随机盐，大小为8-16字节，与密码一起存储。

此外，你可能还想对上述任何PBKDF的输出应用额外的KBKDF（基于密钥的键派生方案）。这使得可以使用bcyrpt的输出用于其他密钥等。KBKDF适用于具有足够熵量的数据，因此通常需要很少的时间（例如使用NIST SP 800-108兼容计数器模式KDF）。我想这应该被考虑为“专家模式”。

- Maarten Bodewes

---

@JeevanJose 是的。如果您不进行哈希处理，中间人攻击或受损的中间服务器可能会看到用户的明文密码。如果您对密码进行哈希处理：尽管攻击者可以看到（并重新使用）哈希密码，但用户的明文密码是安全的，因此使用相同密码的用户在其他地方的帐户将不会被破坏。双重哈希并不需要太多的工作量，而增加的安全性是非常值得的。防止密码重用是一个更困难的问题。 :) - Xcelled

@Jonathan 是的。一遍又一遍地打那个东西很快就让人厌烦了 :P - Xcelled

@JeevanJose 双重哈希是相当可疑的。它仅保护已经受到保护的SSL/TLS会话免受窃听。由于主动MITM可能会更改登录页面本身，攻击者可以注入代码以检索密码。大多数加密专家都不建议使用它。如果您要实现双重哈希，请确保在客户端上进行一些性能测试，并基于此做出决策。UTF-8 / ASCII范围是大多数运行时环境和加密标准的默认编码。UTF-8编码任何 Unicode代码点 - 就像UTF-16BE和LE一样。在任何情况下都要删除BOM！ - Maarten Bodewes

@owlstead 完全没有意识到那是一个网页。从原帖的措辞来看，它听起来像是一个独立的:P，但现在我看到了 asp 标签。在这种情况下，是的，他有比双重哈希更紧迫的问题要解决。 - Xcelled

@Xcelled194 哦...对不起，看来我错过了那个。 - initramfs

Answer 2

你对bcrypt很擅长。

来自黑客的伟大研究: https://crackstation.net/hashing-security.htm#faq Sophos的额外验证: http://www.sophos.com/en-us/medialibrary/PDFs/other/sophossecuritythreatreport2013.pdf

bcrypt也是c#库的一部分： http://msdn.microsoft.com/en-us/library/windows/desktop/aa375383(v=vs.85).aspx

- Jonathan

---

虽然您可以假定 Pinvoke 与您链接的库，但它不是 C# 库。 - Nicole DesRosiers

Answer 3

进行密码哈希的主要原因是：

a. 密码明文不会通过网络传输（主要原因）。

b. 密码明文不会在服务器上持久化存储（次要原因）。

因此，对于您的设置-您没有执行a。相反，依赖于SSL。如果可能的话，我认为您仍应在客户端进行哈希。这样可以为将来的更改留下更多余地，并且一般来说，密码应该比内容数据具有更高的安全性/保护性。

另外，我不知道您可能支持哪些服务器应用程序/可扩展性，因此将密码与代码隔离可能仍然是一个额外的问题。

至于实际的算法/工具来执行哈希-我没有安全专业知识:)

- Vivek

---

我同意他必须使用bcrypt两次。事实上，我在另一个答案中已经说过了... http://stackoverflow.com/a/17887940/1163742 至于安全性，Bcrypt绝对是正确的选择。最后一点提示：注意大小写。如果您对哈希进行不区分大小写的比较（例如在SQL中），您将得到许多错误的成功结果。 - Xcelled

事实上，我在这里关于客户端加密价值的问题提出了一个问题http://stackoverflow.com/a/17862000/2025666，从那里得到的思想是客户端加密可能不值得开销。其次，目前我正在编写一个phonegap应用程序，因此我需要考虑移动设备的加密强度。更不用说我必须首先找到一个支持加密算法的好的javascript库。 - reggaemahn

@JeevanJose 你要加密什么？你知道SSL流（连续加密）会产生和或多于散列密码的开销吗？密码应该在客户端登录时进行一次哈希。这是一次性操作，但你的SSL流将在其寿命内不断运行加密转换。然而，任何现代手机都应该有足够的功率来胜任这两项任务。如果我是你，我会遵循制作最佳应用程序的建议，然后使用分析器调整性能，以防这成为问题。 - Xcelled

@Xcelled194 目前我只关心“哈希”密码。你说的正是我的意思。如果在客户端进行哈希，就需要加上我的哈希时间+SSL加密时间。对于许多仍在使用的塞班手机这样的慢速设备，这是否需要花费不必要的时间？ - reggaemahn

@JeevanJose 不要在没有测试的情况下做出假设。这会花费更长时间，只是问题在于需要多长时间。进行一些试运行。另外，我完全忽略了你正在制作一个网页。在这种情况下，您有比双重哈希更紧迫的问题。 - Xcelled