【问题标题】:how to safely store the password salt如何安全地存储密码盐
【发布时间】:2016-04-01 01:38:54
【问题描述】:

我使用pbkdf2 对密码进行加盐和哈希处理。我知道盐必须是未加密且可访问的,因此我可以在验证中再次使用它。每个密码的盐必须是可访问的,这样我就可以对要验证的密码进行加盐和哈希处理,并将其与存储的密码进行比较。

我想像这样储存盐

假设 salt 始终是一个固定长度的字符串,例如 10 个字符

finalPassword = salt + password;
//save finalPassword in the db

然后去验证

salt = getFirst10CharsOf (finalPassword);

hash to-be-validated password with that salt

compare hashed password with the saved one

我的问题是,如果黑客足够聪明,可以获取我的散列密码,那么是什么阻止她看到我的代码中的 getFirst10CharsOf 部分并获取一些盐,以便她可以轻松解密几个散列?

我发现了很多理论,但我不知道如何在实践中安全地储存盐。所以它们总是可以只访问验证码,而不是每个人。

谢谢

【问题讨论】:

  • 这个问题似乎是另一个SO Question的延伸。
  • @zaph 是的,它在盐部分指定,并询问我保存盐的想法是否正确。

标签: hash passwords password-protection salt


【解决方案1】:

salt 不需要保密,它用于以下几件事:1. 使彩虹表的使用更加困难;2. 确保两个密码不会散列到相同的值,这样如果一个密码被泄露,其他相同的密码不是(不同的哈希值)。

【讨论】:

    【解决方案2】:

    是什么阻止了她在我的代码中看到 getFirst10CharsOf 部分并获得一些盐,

    什么都没有

    这样她就可以轻松解密几个哈希?

    使用单向哈希的关键在于您无法解密它们(即使使用盐也不行)。

    使用盐(每次使用不同的盐)的意义在于,您不能用彩虹表强行使用它们。

    我不知道如何在实践中安全储存盐。

    只需将它们与散列密码一起存储即可。没有必要让它们无法访问。

    所以它们总是可以只访问验证码,而不是每个人。

    如果可以将数据存储在您的代码可以访问的某个地方,但有人会非法访问代码运行所在的系统,那么一开始就不需要散列密码。

    【讨论】:

    • 不错的答案。所以,要明确一点,我的方法是安全的,我应该部署它吗?
    • @slevin - 实际上盐应该长于 10 个字符。有一个广泛使用的common format,如何存储盐。我建议找到一个现有的 BCrypt/PBKDF2 库,它可以生成安全的盐并生成这种未来证明格式。
    猜你喜欢
    • 2011-12-29
    • 1970-01-01
    • 2011-11-08
    • 1970-01-01
    • 2018-05-13
    • 2011-05-09
    • 2017-06-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多