我们是否应该对唯一且随机的信息进行加盐处理答案

【问题标题】：Should we salt informations that are unique and random我们是否应该对唯一且随机的信息进行加盐处理
【发布时间】：2019-07-30 05:54:07
【问题描述】：

Salt 用于在数据库中存储密码以防止字典攻击和彩虹表。

但是，假设我们需要存储关于用户的唯一和随机（敏感）信息。在散列之前对这些信息进行盐分还有优势吗？

不会加盐，在这种情况下，只是为已经随机的数据添加随机性（不像人工输入的密码）？

【问题讨论】：

独特和随机是什么意思？盐只是用来防止解密。就是这样。如果您必须保护该唯一且随机的信息，请使用盐。如果你不这样做，那就别管它了。
你能详细说明unique and random吗？
@Kianii 散列不加密，它们散列。字典攻击和彩虹实际上是试图找到难以反转的哈希函数的原像或副像。
@kelalaka 确定性加密呢？
随机：无法识别模式，唯一：对于数据库中的每个 r1，不存在 r2 使得 r1 = r2

标签： security hash salt

【解决方案1】：

这取决于您的信息的机密性程度以及这些数据被泄露时的后果。是PII SSN 或 DOB 之类的信息吗？

您提到您的数据是随机且唯一。这意味着很难识别一个模式。如果模式足够随机，则可能不需要对数据进行加盐处理。如果您使用盐腌，那么您还将承担保护这些盐的额外责任。

我建议使用低权限帐户、强化服务器、身份验证、授权来保护您的数据并最大限度地减少攻击面。

同样，您应该根据CIA 原则对数据进行分类后得出结论。

【讨论】：

如果随机和唯一数据的大小很小，那么很容易找到。比特币矿工在一年内达到了 ~2^90 哈希值。
同意你的评论，这是我在不知道帖子数据细节的情况下的一般回应。基于数据分类（高、中、低），然后我们应该决定是否加盐。否则，我们可以使用其他措施来保护数据。
"那么你将有额外的责任保护这些盐分" 你是什么意思？盐，但定义，不是敏感信息。如果你必须保护盐，那么它就不是盐，而是辣椒，辣椒的处理与盐的处理非常不同（而且比盐弱得多）。

【解决方案2】：

这在很大程度上取决于搜索空间的大小。例如，我们可以假装社会安全号码既是随机的又是唯一的（它们实际上也不是，但为了讨论的目的，我们将假装它们是）。如果您正在对 SSN 进行哈希处理，您不仅需要盐，而且盐还不够。为什么？因为现有的 SSN 不到 100 亿个。为这些创建一个彩虹表是微不足道的。即使使用盐，暴力破解也不是那么难，即使值是唯一且随机的。

因此，为了保护存在于小搜索空间中的随机且唯一值，我们必须使用 PBKDF2 之类的拉伸算法，而不仅仅是哈希。拉伸算法的重点是使计算哈希非常慢。

拉伸算法总是包含盐。但它不一定是随机盐。它可能是确定性的（某些数据库标识符 + 用户 ID，例如“com.example.mygreatapp:alice”）。但是对于一个小的搜索空间，您仍然需要它对每个用户都是唯一的，因为搜索空间中的项目太少了。

另一方面，如果您的随机且唯一的数据代表较大的搜索空间（不少于 2^64，理想情况下至少为 2^80），并且该搜索空间是稀疏的（您只使用了很小的一部分）法律元素），那么可能不需要盐渍和拉伸。

【讨论】：