在数据库中存储密码时使用盐，以防止字典攻击和彩虹表。
但是，假设我们需要存储有关用户的唯一和随机（敏感）信息。在对这些信息进行哈希处理之前对其进行腌制是否还有一个优势？
在这种情况下，不加盐就可以为已经随机的数据添加随机性（与人工输入的密码不同）吗？
答案 0 :(得分：1)
这取决于您的信息机密以及此数据被泄露时的后果。是PII信息，例如SSN或DOB？
您提到您的数据是随机和唯一。这意味着识别 模式非常困难。如果模式足够随机，则可能不需要加盐。如果您要加盐，那么您还要承担保护这些盐的责任。
我建议使用低特权帐户，服务器强化，身份验证，授权来保护您的数据并最大程度地减少攻击面。
同样，在基于CIA原则对数据进行分类之后，您应该得出结论。
答案 1 :(得分：1)
这在很大程度上取决于搜索空间的大小。例如，我们可以假装社会保险号既是随机的又是唯一的（实际上也不是，但是出于讨论的目的，我们假装它们是）。如果您要散列SSN，则不仅需要添加盐，而且添加盐还不够。为什么？因为现有的SSN少于100亿个。为那些创建彩虹表是微不足道的。即使加了盐，即使这些值是唯一且随机的，也不难用暴力破解。
因此，要保护存在于较小搜索空间中的随机且唯一的值，我们必须使用诸如PBKDF2之类的扩展算法，而不仅仅是散列。拉伸算法的要点是使哈希计算非常慢。
拉伸算法总是包含盐。但这不一定是随意盐。它可以是确定性的（某些数据库标识符+用户ID，例如“ com.example.mygreatapp：alice”）。但是对于小的搜索空间，您仍然需要每个用户唯一的搜索空间，因为搜索空间中的项目很少。
另一方面，如果您的随机且唯一的数据表示较大的搜索空间（不少于2 ^ 64，理想情况下至少为2 ^ 80），并且该搜索空间是稀疏的（您只使用了很小一部分的法律元素），则可能不需要加盐和拉伸。