首页 文章

散列密码时,我应该在数据库中存储散列函数名吗?

提问于
浏览
2

关于保存用户密码的盐渍哈希版本,我在数据库中保存哈希盐渍密码和哈希之前使用的盐 .

我是否还应该在DB中保存用于散列盐渍密码的算法的名称(例如SHA1或MD5 [我不会使用MD5!])所以如果有人在我使用的算法中发现了违规,我可以切换到将来的用户使用另一种算法?

注意:我不是在谈论用于生成随机散列的算法 .

3 回答

  • 0

    如果您首先使用强加密哈希函数,则可能没有理由切换到更强的哈希函数 .

    有一个网站keylength.com,其中概述了计算中信息安全的最重要建议 . 目前,所选择的散列函数应该具有160位或更多的长度 - 越多越好 .

    如果您正在寻找通用格式,您可以使用modular crypt format,其中包含哈希函数的标识符,使用的盐,摘要以及表单中的更多信息(例如成本因子):

    $<id>$[<parameters>$]<salt><digest>
    

    Many suggest to use bcrypt for passwords作为其附加成本参数是调整散列的计算成本 .

  • 4

    是的,这是一个好主意 . 它的成本很低(每个条目几个字节),这意味着您可以在以后更改和改进存储密码的方式 . 例如,假设您几年前开始在MD5上使用此方法 - 现在通过在下次登录时更新每个用户的密码哈希来升级到SHA1或其他更安全的东西会变得微不足道 .

    请注意,您应该使用类似PBKDF2的内容来哈希密码,而不仅仅是盐渍哈希 .

  • 0

    这是个人喜好的事情之一 . 如果找到散列算法的弱点,则需要更改用户密码的存储和验证方式 . 有多种方法可以做到这一点,并且存储哈希的名称是一种有效的替代方法 . 假如说

    • 如果发现弱点,您希望切换到更好的哈希替代方案

    • 你're not storing plaintext passwords (which if you are, you'已经有更大的问题)

    您需要使用新的哈希算法自动为您的用户生成新密码(并通知他们),或让他们在下次登录时更改或验证他们的密码 . 存储算法的方法有助于促进第二种选择(我认为这是更好的选择) .

    从技术上讲,如果数据库被渗透,存储哈希算法不会使密码的安全性降低,并且当您希望更改算法时,它可以提供更大的灵活性 .

相关问题