加盐密码
Salted Passwords
我一直在阅读有关存储和检查用户密码的正确程序，但对盐有点困惑。
我认为它们是为了防止使用彩虹表等工具，但对我来说，将盐与哈希一起存储的想法似乎是一个潜在的安全问题。一处数据过多，我不喜欢。
我想 运行 的想法是使用 'lucky number' 从密码散列的一部分创建盐。
基本上，除了选择密码外，用户还会选择 'lucky number'。然后，此数字将用作起始索引，以从散列传递中检索盐。
所以一个非常基本的例子就是这样。
Pass = "Password"
Lucky Number = "4"
Pass Hash = "00003gebdksjh2h4"
Salt Length = "5"
Resulting Salt = "3gebd"
我的想法是，由于 'lucky number' 不需要存储，盐也会花费计算时间来计算，因此使任何攻击更加困难。 Plus 表示存储的数据略少。
它不会增加更多的安全性。使用 rainbow table 的目标是获得字典单词和相关哈希值组合的映射。通过为您计算的每个密码哈希使用或多或少不同的盐（通常不应该在字典中找到），您迫使攻击者为每个条目生成一组新的彩虹 tables ，这在计算上会非常昂贵。在任何时候（除了生成散列table）攻击者都不会计算散列，所以你的策略在这里失败了。
另一方面，当使用常规字典攻击时，攻击者只需要一个恒定时间的计算来计算盐值，对于他必须生成的数百万或更多哈希组合，他只需计算一次盐值.它只有在计算成本高于生成所有这些时才有效，但每次用户想要登录时你都必须进行相同的计算，这是不可行的。
我一直在阅读有关存储和检查用户密码的正确程序，但对盐有点困惑。
我认为它们是为了防止使用彩虹表等工具，但对我来说，将盐与哈希一起存储的想法似乎是一个潜在的安全问题。一处数据过多，我不喜欢。
我想 运行 的想法是使用 'lucky number' 从密码散列的一部分创建盐。 基本上，除了选择密码外，用户还会选择 'lucky number'。然后，此数字将用作起始索引，以从散列传递中检索盐。
所以一个非常基本的例子就是这样。
Pass = "Password"
Lucky Number = "4"
Pass Hash = "00003gebdksjh2h4"
Salt Length = "5"
Resulting Salt = "3gebd"
我的想法是，由于 'lucky number' 不需要存储，盐也会花费计算时间来计算，因此使任何攻击更加困难。 Plus 表示存储的数据略少。
它不会增加更多的安全性。使用 rainbow table 的目标是获得字典单词和相关哈希值组合的映射。通过为您计算的每个密码哈希使用或多或少不同的盐（通常不应该在字典中找到），您迫使攻击者为每个条目生成一组新的彩虹 tables ，这在计算上会非常昂贵。在任何时候（除了生成散列table）攻击者都不会计算散列，所以你的策略在这里失败了。
另一方面，当使用常规字典攻击时，攻击者只需要一个恒定时间的计算来计算盐值，对于他必须生成的数百万或更多哈希组合，他只需计算一次盐值.它只有在计算成本高于生成所有这些时才有效，但每次用户想要登录时你都必须进行相同的计算，这是不可行的。