passwords - Web 应用程序 - 存储密码

Question

我错过了什么吗？是否有任何额外的步骤将密码存储到数据库？

存储密码:
在对该主题进行尽可能多的研究之后，我得出的结论是，将用户密码存储在 Web 应用程序数据库(在我的情况下为 MySQL+PHP)中的最佳方法如下:

分配站点范围的静态盐。 (16 个兰特字符，包括 0-9、a-z、A-Z、[]/*-')

为每个用户分配一个随机盐(存储在数据库中)。

存储结果 hash_function($userPassword + $sitewideSalt + $randomSalt)

将 $randomSalt 存储在生成的哈希旁边。

使用 bcrypt 可调工作负载
散列

攻击#1:攻击者通过 SQL 注入(inject)转储数据库。
数据库结果
我们的 hash_function 和随机数
用户盐。

转储后，攻击者可以
获取 $用户密码 和
$随机盐通过查找他自己的帐户。然后通过猜测哈希
诸如md5之类的功能他可以启动一个
彩虹攻击
$全站盐 .但这可能需要高达 1.41 亿
世纪[1]。

通过使用这种类型的安全性 不允许 DB 转储损害存储的密码 .用户仍然需要找到 $全站盐通过另一种方法。

攻击#2:攻击者找到一个本地文件包含 (LFI) 向量。
攻击者可以获得我们 Web 应用程序的原始代码。
通过可能的 LFI 利用 Web 应用程序后
或 RFI[2] 攻击者读取
我们网站的源代码
应用程序并获得我们的简单
算法和存储
$全站盐 .

下一步去哪里？
现在攻击者拥有了两种盐，他可以开始使用彩虹来获取实际密码。除了他必须制作一张彩虹 table 对于每个 用户，因为每个用户都有不同的随机用户特定盐($randomSalt)。

"A modern server can calculate the MD5 hash of about 330MB every second. If your users have passwords which are lowercase, alphanumeric, and 6 characters long, you can try every single possible password of that size in around 40 seconds."
"...CUDA, you can put together your own little supercomputer cluster which will let you try around 700,000,000 passwords a second..."[3]

我们现在需要做的是通过使用诸如 bcrypt 之类的耗时算法来扩展散列函数。 bcrypt 的工作负载因子可以是简单散列函数的 5-6 个数量级。破解一个密码可能需要数年而不是几分钟。作为奖励，bcrypt 已经为每个散列生成了一个随机盐，并将其存储在生成的散列中。

http://www.grc.com/haystack.htm

http://www.wildcardsecurity.com/security101/index.php?title=Local_File_Inclusion

Answer 1

干得好!对我来说看起来很完整。

我唯一的建议是:

旋转服务盐。

设计一种方法来定期轮换服务范围的盐，并定期进行锻炼。

例如，在生成新的服务 salt 后，将其用于所有新帐户和任何密码更改。当现有用户尝试登录时，使用旧服务盐对他们进行身份验证。如果成功，则使用新的服务盐(以及可选的新用户特定盐)更新其哈希。对于“一段时间”未登录的用户，代表他们随机生成一个新密码。这将为放弃您网站的用户“保持”安全性，迫使那些返回的用户使用密码重置工具。 (“某个时间”=您喜欢的任何时期)。

不要硬编码你的服务盐。

不要让 LFI 攻击损害您的服务盐。在启动时将服务盐提供给您的应用程序，并将其保存在内存中。要破坏服务盐，攻击者需要能够执行代码以从内存中读取盐。如果攻击者可以做到这一点，那么无论如何你都很好。 =)

不要重复使用用户盐。

寻找机会为用户提供新盐。用户更改密码？生成一个新的随机盐。如果攻击者能够随时获取他的哈希值，这将进一步阻碍暴力破解您的服务器范围的盐。再加上定期轮换你的服务盐，我敢打赌你对暴力破解有很强的威慑力。

(如果其他人有其他想法，请将其标记为社区 wiki)。