现在我正在从事一个金融项目。在这里,团队正在考虑对MD5
使用password hashing
。
但是,今天很容易复制SHA1
或MD5
密码以进行解密,如果它们是复杂密码,则包括以下内容:
My$uper$ecur3PAS$word+448
,您可以使用在线页面对其进行解密,并且存在。
中小型开发人员(包括我在内)使用这些hashing methods
,但我认为不足以为数据库提供安全性。
(不包括firewalls
,network security
,iptables
等)。
有人可以为我提供解决此漏洞的更好方法的线索吗?
答案 0 :(得分:3)
您的想法是正确的,永远不要将MD5和SHA1用于密码哈希。我会按照优先顺序推荐以下内容:
如果用您使用的语言/框架标记问题,我会推荐特定的库或方法。
另外请注意,加密不是此处使用的正确词。这些是密码散列算法,而不是加密算法。
答案 1 :(得分:3)
根据OWASP Password Storage Cheat Sheet,推荐为:
对于大多数与安全性相关的用例,
- Argon2是密码哈希竞赛的获胜者,应被视为新应用程序的首选;
- 需要许多平台上的FIPS认证或企业支持的PBKDF2;
- 在需要抵抗任何/所有硬件加速攻击但不需要支持的情况下进行加密。
- bcrypt,其中不提供PBKDF2或scrypt支持。
MD5和SHA1不受保护,因为可以发现与这些算法的冲突。换句话说,给定一个输入及其哈希值,就有可能推导具有相同哈希值的另一个输入。
SHA-2哈希算法组可在许多安全用例中得到保护,但不能用于密码哈希,因为与上述算法相比,它们的速度非常快。而性能并不是密码散列所不希望的,因为这会使攻击者更容易通过在短时间内尝试各种密码来进行暴力攻击。
因此,上述4种算法在内存,计算能力和时间方面都是昂贵的。这些值通常经过参数设置,以便随着新技术随着时间的推移提高计算能力而可以将它们调整为较高的值。因此,在使用这些算法时,正确选择工作因子值很重要。设置一个非常低的评估者可能会失败。
除了应该使用盐之外。
再次从相同的OWASP来源:
在创建每个存储的凭证时(不仅是每个用户或整个系统)生成唯一的盐;
使用加密强度高的随机数据;
- 在存储允许的情况下,使用32字节或64字节的盐(实际大小取决于保护功能);
- 方案的安全性不取决于盐的隐藏,分裂或遮盖。
盐有两个用途:
- 防止受保护的表单泄露两个相同的凭据,并且
增强熵用于保护功能,而无需依赖凭证的复杂性。第二个目的是使对单个凭证的预先计算的查找攻击和对总体的基于时间的攻击变得难以处理