你在哪里储存盐串？(Where do you store your salt strings?)

你在哪里储存盐串？(Where do you store your salt strings?)

当数据库存储的密码为空时，我一直使用适当的每个入口的盐串。 根据我的需要，将盐储存在散列密码旁边的数据库中，一直工作正常。

然而，有些人建议将盐与数据库分开存储。 他们的论点是，如果数据库受到威胁，攻击者仍然可以建立一个彩虹表，考虑到特定的盐串，以便一次破解一个帐户。 如果这个帐号具有管理权限，那么他甚至可能不需要破解任何其他的权限。

从安全的角度来看，将盐分储存在不同的地方是值得的吗？ 在同一台机器上考虑使用服务器代码和数据库的Web应用程序。 如果这些盐存储在该机器上的平面文件中，那么可能的是，如果数据库受到威胁，那么盐文件也将被使用。

有没有推荐的解决方案呢？

I've always used a proper per-entry salt string when hashing passwords for database storage. For my needs, storing the salt in the DB next to the hashed password has always worked fine.

However, some people recommend that the salt be stored separately from the database. Their argument is that if the database is compromised, an attacker can still build a rainbow table taking a particular salt string into account in order to crack one account at a time. If this account has admin privileges, then he may not even need to crack any others.

From a security perspective, is it worth it to store salts in a different place? Consider a web application with the server code and DB on the same machine. If the salts are stored in a flat file on that machine, chances are that if the database is compromised, the salts file will be, too.

Are there any recommended solutions to this?

最满意答案

彩虹表的要点是，它们是提前创建的并且大量分发，以节省他人的计算时间 - 它只需要长时间生成彩虹表，因为它将直接破解密码+盐组合（自有效地生成彩虹表时所做的工作是预先运行强制哈希的计算），因此通过了解盐可能“生成彩虹表”的论据是虚假的。

只要它们在每个用户的基础上，将盐存储在单独的文件中就没有任何真正的意义 - 盐的一点只是让它使得一个彩虹表不能破坏数据库中的每个密码。

The point of rainbow tables is that they're created in advance and distributed en masse to save calculation time for others - it takes just as long to generate rainbow tables on the fly as it would to just crack the password+salt combination directly (since effectively what's being done when generating rainbow tables is pre-running the calculations for brute-forcing the hash), thus the argument that by knowing the salt someone could "generate a rainbow table" is spurious.

There's no real point in storing salts in a separate file as long as they're on a per-user basis - the point of the salt is simply to make it so that one rainbow table can't break every password in the DB.