Web应用程序-存储密码
我错过了什么吗？是否有其他步骤存储数据库的密码？
存储密码：
在对该主题进行尽可能多的研究之后，我得出结论:在web应用程序DB (我的例子是MySQL+PHP)中存储用户密码的最佳方法如下：
- 分配一个站点范围的静态盐。(16兰特字符包括0-9，a-z，A-Z，[]/*-‘)
- 为每个用户分配一个随机盐(存储在DB中)。
- 存储结果hash_function($userPassword + $sitewideSalt + $randomSalt与结果哈希一起)。
- 使用bcrypt可调整的工作负载哈希
- Attack #1:攻击者通过SQL注入转储DB。
我们的hash_function和每个用户盐的随机性的基本数据结果。
转储之后，攻击者可以通过查找自己的帐户获得$userPassword和$randomSalt。然后，通过猜测哈希函数(如$sitewideSalt. )，他可以在md5上发起彩虹攻击。但这可能需要141万centuries1。
通过使用这种类型的安全性，不允许数据库的转储危及存储的密码。用户仍然必须通过另一种方法找到$sitewideSalt。
- Attack #2:攻击者找到了本地文件包含(LFI)向量。
更接近的攻击者可以获得我们的web application.的原始代码。
After exploiting the web application through a possible LFI or RFI[2] the attacker reads the source code for our web application and obtains our simple algorithm and the stored$sitewideSalt.
下一个在哪里？
现在攻击者拥有两种盐，他可以开始彩虹来获得实际的密码。但他必须为每个用户制作一个彩虹表，因为每个用户都有不同的随机用户特定盐($randomSalt)。
“现代服务器可以计算每秒约330 40的MD5哈希。如果您的用户有小写、字母数字和6个字符长的密码，您可以在大约40秒内尝试每一个可能的密码。”
"...CUDA，你可以把你自己的小型超级计算机集群放在一起，这样你就可以每秒尝试大约7亿，000,000个密码……“
我们现在需要做的是使用bcrypt等耗时的算法来扩展散列函数。bcrypt的工作负载因子可以是简单散列函数的5-6个数量级。破解一个密码可能需要数年而不是几分钟。作为一种奖励，bcrypt已经为每个散列生成了一个随机盐，并将其存储在结果的散列中。
- http://www.grc.com/haystack.htm
- http://www.wildcardsecurity.com/security101/index.php?title=Local_File_Inclusion
回答 2
Stack Overflow用户
发布于 2011-06-26 03:14:03
干得好！在我看来很完整。
我只会提出以下建议：
旋转服务盐.
设计一种方法，定期旋转服务范围内的盐，并定期进行锻炼。
例如，在生成新的服务盐之后，将其用于所有新帐户&任何密码更改。当现有用户尝试登录时，使用旧的服务盐对其进行身份验证。如果成功的话，使用新的服务盐更新它们的散列(并且可以选择一个新的特定于用户的盐)。对于在“一段时间内没有登录”的用户，代表他们随机生成一个新密码。这将“保持”用户的安全，谁已经放弃了你的网站，迫使那些返回使用密码重置设施。(“某段时间”=无论你喜欢哪段时间)。
不要硬编码你的服务盐.
不要让LFI攻击损害您的服务盐。在启动时向应用程序提供服务-salt，并将其保存在内存中。要破坏服务盐，攻击者需要能够执行代码从内存中读取salt。如果攻击者能做到这一点，你就会被很好的冲洗。=)
不要重用用户盐.
寻找给用户新盐类的机会。用户更改密码？产生一个新的随机盐。这进一步阻碍了蛮力，迫使您的服务器范围的盐，如果攻击者能够获得他的哈希时，他觉得它。再加上定期轮换你的服务-盐，我敢打赌你对暴力有很强的威慑力。
(如果其他人有更多的想法，将其标记为社区wiki )。
Stack Overflow用户
发布于 2011-06-24 11:19:29
使用BCrypt处理密码是唯一的步骤，或者更确切地说，包括以下步骤：
- 获取密码，提供给BCrypt库。
- Store导致哈希。
- 将密码与散列进行比较。
您还忘记了这个链接：http://codahale.com/how-to-safely-store-a-password/，这是您引用的引号。
https://stackoverflow.com/questions/6464662
复制相似问题
腾讯云开发者
