3

我在 php 5.3+ 中使用 bcrypt 进行密码散列

我知道 bcrypt 使用随机盐，该盐内置到每个项目的结果哈希中。这使得破解每个哈希变得困难，并防止破解

我不知道是否还有充分的理由使用额外的应用程序级全局密钥。

例如，不仅仅是将密码字符串散列，例如“password1”使用内置在 bcrypt 生成系统中的随机盐，将“password1”转换为 bcrypt 散列（根据此处：https ://gist.github.com/1053158 ）：$2a$08 $mjQAZ5cZi5B9u6zpUU4mGuRcvtxr1K.9ncYpxCdG.YhlD8yFG2mXK

我还可以创建一个常量，例如： "@#$%$%&BDFGG@$%BNG$Y^$%SEHYSZTHN$%" ，将该常量放入应用程序（放入应用程序源代码或应用程序的配置文件） , 并将其附加到任何要散列的字符串。因此 "password1"+"@#$%$%&BDFGG@$%BNG$Y^$%SEHYSZTHN$%" -> 将被散列到与仅 "password1" 不同的散列中。$2a$08$xFgULsrpoIYlbxp1IG3H8.kdVggyhm4aTQXrP2Ptu25nMBUjBdrrK

显然，在应用程序本身的上下文中，这并没有多大帮助。如果有人在正在运行的系统上尝试密码“password1”，他们就会成功，因为他们会自动获得全局密钥以供使用。但如果他们只有数据库或只能访问数据库，似乎全局密钥可能是一个额外的障碍？因为在不知道全局密钥的情况下，他们将不得不破解 ""password1@#$%$%&BDFGG@$%BNG$Y^$%SEHYSZTHN$%" 而不是仅仅破解 "password1"。

我可以想象可能存在一些潜在的好处：

  • 这可能真的会阻碍仅使用受损数据库来破解哈希？

以及可能存在的一些模糊的缺点：

  • 这为所有被散列的字符串引入了一个公共线程，如果散列已知，这可能会使破解散列变得更容易。
  • 它增加了数据的脆弱性。如果全局密钥丢失，例如在服务器迁移期间或其他任何情况下，数据现在就是垃圾。

所以我想弄清楚拥有一个全局密钥是否是一个好主意，或者每个项目的随机盐是否足够，以及你想要的。有谁知道使用全局密钥的任何实现，或建议使用它的研究？

4

2 回答 2

3

盐的唯一目的是击败预计算攻击（例如，彩虹表）。您所说的“全球盐”实际上是一个秘密密钥。

关于这是否有用，意见不一。它有助于防御的唯一威胁模型是攻击者可以获取数据库内容但无法访问您的源代码的威胁模型。就个人而言，我认为这是一种足够狭隘的可能性，因此没有必要进行防御，并且正确地进行防御所需的努力是没有根据的。

于 2012-04-26T06:29:40.243 回答
0

加盐和拉伸的目的是让黑客在访问数据库时难以破解密码。

如果您在应用程序中添加额外的全局盐，那么您基本上是在应用程序和数据库之间分配您的登录过程，这使事情变得比必要的更复杂，并为攻击打开了更多的场所。

你打算在数据库中存储什么，包括全局盐的哈希值？然后，在登录过程中，您将需要在 db 和 app 之间传输什么？无论如何，你的应用程序和数据库之间的通信应该是安全的（否则你的加盐系统很容易被中间的人破坏）。

如果黑客只能访问 db 而从不访问应用程序，可能会有一点好处，但老实说，这在今天是一个非常微小的不现实案例。黑客将在您的数据库之前访问您的应用程序。这不值得努力。而且，我什至可能是错的。

很多时候，当谈到安全性时，人们会想到“新”的想法，结果却被黑客破坏了，因为没有正确识别和研究极端案例。它是密码学的经典之作。数以千计的这些想法都以巨大的失败告终，并使使用它们的人付出了很多痛苦。创造力是密码学的责任。

坚持经典的安全通信 + 随机项目级加盐方案。

于 2012-04-24T21:50:56.020 回答