我认为这种方法没有直接问题。特别是如果您除了使用每个用户的盐之外，还使用每个网站的盐。这样你的组合盐就足够复杂了。密码散列中盐的主要功能是防止彩虹表。而且您不需要高度随机的盐。

我仍然不会那样做，因为使用随机盐是标准做法。发明自己的加密货币通常是个坏主意，因为很容易出错。因此，除非有充分的理由不这样做，否则我只会遵循标准做法。

IMO 使用具有足够迭代次数的 KeyDerivationFunction 来减缓暴力攻击比担心盐的随机性更重要。有一些盐是必不可少的，但只是你需要的东西之一。

Salt 应始终包含由加密方法生成的随机位。主键不是随机的；不要这样做！

编辑：我在这里得到的是您的主键本身不会包含足够的熵。可以为每个盐值生成一个单独的彩虹表。你的盐需要包含足够多的熵，这样就不可能生成足够多的表来让攻击者预先计算你的哈希值。

可以将主键用作用户表中的盐吗？

在极少数情况下，这是可以接受的，但即便如此，它也不太可能提供任何真正的好处。基本上，不要这样做。

可能没问题的情况是主键是a）一个大值，b）一个随机值。一个有点人为的例子可能是UUID 类型 4被用作主键。

您从中获得的唯一好处是为每个用户节省了几个字节。这完全可以忽略不计，即使您拥有数百万用户，当前的数据库引擎也不会注意到这种节省。

但是，在软件开发需求和安全性方面，使用主键作为盐存在主要缺点：

在软件开发方面：

• 好的开发团队会使用OR/M，好的 OR/M 真的很喜欢独占控制主键。这开启了良好的性能优化。一个例子是NHibernate Hi/Lo 算法，它使 NHibernate 能够“延迟写入”到数据库，从而加快速度。

• 好的数据库也喜欢对主键进行独占控制。而且他们经常通过主键来构建他们的数据文件，从而通过正确的主键来获得重大的性能提升。

• 许多数据库喜欢主键很小，fx 是一个 32 位整数，因为主键通常包含在 RAM 中保存的索引中。

在安全方面：

• 您还没有说您实际使用什么作为主键（例如UUID、社会安全号码或自动递增的 32 位整数？）。但是，最常见的情况是自动递增的 32 位或 64 位值（第一个用户的密钥为“0”，第二个用户的密钥为“1”，依此类推）。这对于密码盐来说还不够好。

最终答案：这取决于您实际使用的 primary key。但在几乎所有情况下，这都是一个坏主意。

可以将主键用作用户表中的盐吗？

这绝对不行。为每个用户使用随机盐。使用河豚（标准）或类似的东西。

除了接受随机盐之外，河豚是自适应的，这意味着随着 CPU 变得更快，您可以延长计算时间。