我在 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"。
我可以想象可能存在一些潜在的好处:
- 这可能真的会阻碍仅使用受损数据库来破解哈希?
以及可能存在的一些模糊的缺点:
- 这为所有被散列的字符串引入了一个公共线程,如果散列已知,这可能会使破解散列变得更容易。
- 它增加了数据的脆弱性。如果全局密钥丢失,例如在服务器迁移期间或其他任何情况下,数据现在就是垃圾。