我对密码安全保存有点困惑。假设我有带有用户帐户表的数据库。这是我保存密码的地方。此时我正在使用盐渍sha1。
我读过基于 Blowfish 的函数比 sha1 更好,因为它们需要更多时间来处理请求。
是否有任何理由不使用盐渍 sha1 并将登录尝试次数限制在某个合理的数字(例如每小时 50 次)作为暴力攻击的“防火墙”?
使用这个数据库的人不需要暴力破解任何东西,因为他可以通过查询更改记录。
使用基于河豚的函数,您肯定是指BCrypt哈希函数。正如您已经说过的那样,BCrypt 的设计速度很慢(需要一些计算时间),这是与其他快速哈希函数相比的唯一优势,但这是至关重要的。
使用现成的 GPU,您可以每秒计算大约3 个 Giga哈希值,因此您可以在不到2 毫秒的时间内暴力破解包含 5'000'000 个单词的整个英语词典。即使 SHA-1 是一个安全的散列函数,它也不适合散列密码。
BCrypt 有一个成本因素,可以适应未来的硬件,因此速度更快。成本因素决定了执行多少次散列迭代。最近我写了一篇关于散列密码的教程,我会邀请你看看它。
您关于限制登录尝试的观点是有道理的,但散列应该保护密码,以防攻击者访问数据库(SQL 注入)。当然,您可以限制登录尝试,但这与散列无关,您甚至可以在这种情况下存储密码明文。
将密码存储在 Blowfish 中比 SHA-1 更安全,因为到目前为止,还没有报道过获取 Blowfish 加密字符串值的方法。另一方面,SHA-1 确实报告了从加密字符串中获取数据的方法。您不能相信 SHA-1 会阻止某人获取其数据。
如果您愿意接受建议,我认为在存储密码时根本不需要使用双向加密。使用加盐SHA-256方法散列您的用户密码可能是一种选择。允许您的用户通过电子邮件重置自己的密码通常被认为是一个好的策略,它会导致数据集不容易被破解。
如果出于任何原因确实需要双向加密,除了 Blowfish,AES-256 (Rijndael) 或Twofish目前也足够安全,可以处理敏感数据。不要忘记您可以自由地使用多种算法来存储加密数据。
关于暴力破解,它与加密数据库存储几乎没有关系。当您提到攻击方法时,您正在查看完整的安全模型。使用已弃用的算法并通过实施策略来“弥补”以防止易受攻击并不被认为是一种成熟的安全方法。
简而言之
不要把这当作信条:当谈到安全性时,每个人都有不同的要求,你做的研究越多,你的方法就会变得越好。如果您没有使用全面的安全策略完全封装您的敏感数据,您可能会在跟踪过程中遇到令人讨厌的意外。
资料来源:维基百科,http ://eprint.iacr.org/2005/010
是否有任何理由不使用加盐 sha1 并将登录尝试次数限制在某个合理的数字(例如每小时 50 次)作为暴力攻击的“防火墙”?
如果您不使用任何体面的算法加密您的密码,那么您就没有采取基本的安全预防措施。
为什么“只是”阻止登录尝试不安全?
除了您需要阻止所有可能的入口之外,例如:
您还需要信任每个有权访问数据库和服务器的用户,我不希望人们阅读我的密码,但我更不喜欢的是,从元学上讲,您是为我决定的 :-)
也许其他人可以阐明 Blowfish 与 SHA 的讨论,尽管我怀疑那部分是一个可堆叠的格式化问题