cryptography - 除了使用 bcrypt 密码散列的随机项目级盐之外，使用全局 key 是否有整体优势？

Question

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

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

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

例如而不仅仅是散列密码字符串，例如将“password1”转换为带有 bcrypt 生成系统中内置的随机盐的 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”，他们就会成功，因为他们会自动获得全局 key 。但是，如果他们拥有数据库或只能访问数据库，那么全局 key 似乎是一个额外的障碍？因为，不知道全局 key ，他们将不得不破解“password1@#$%$%&BDFGG@$%BNG$Y^$%SEHYSZTHN$%”，而不是仅仅破解“password1”。

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

• 这真的会阻碍单独使用受损数据库破解哈希值吗？

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

• 这为所有经过哈希处理的字符串引入了一个共同线程，如果已知哈希值，这可能会更容易破解哈希值。
• 它增加了数据的脆弱性。如果全局 key 丢失，例如在服务器迁移或其他任何情况下，数据现在都是垃圾。

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

Answer 1

salt 的唯一目的是抵御预计算攻击(例如，彩虹表)。您所描述的“全局盐”实际上是一把 secret key 。

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