可以用散列存储盐吗？ [英] Is it okay to store salts with hashes?

问题描述

我的理解是，盐不是为了保密，它仅仅是为了与任何集中的标准不同，所以你不能开发彩虹表或类似的攻击来打破使用算法的所有哈希，因为盐打破了彩虹桌。我的理解可能不完全正确，所以如果我错了，请纠正我。

在广泛使用的开源软件中，盐会广泛使用因为现在他们可以简单地攻击你的哈希版本，并创建包含盐数据的彩虹表。

当我看到它时，有两种方法可以解决这个问题。首先是用每一个新版本的软件改变盐份，但这并不好，因为新版本的软件将不再能够测试旧密码哈希。

我想到的第二个解决方案是每个密码都存储一个salt;换句话说，每个密码都会得到不同的盐分。缺点是salt必须以某种方式与密码哈希关联，可能只是将它们粘在数据库中的密码旁边。甚至可以使用用户名（可能不会，但可能用户名太短）。

我的问题是，这可以接受吗？将盐直接存储在密码中会带来额外的风险吗？在我看来，将salt存储在源代码中并没有什么不同，因此通过将salt存储在密码中并没有造成安全性损失。

免责声明：我不是将其用于任何现实生活安全系统。事实上，我从来没有设计过任何类型的密码系统。我只是让自己隐瞒有关安全问题的知识。

解决方案

更新例如 passlib for Python。

这些注意生成每个密码salt，并且他们使用适当的散列算法（它不足以仅使用诸如SHA1之类的加密散列;您必须以使其非常缓慢地反转例如循环1000或更多的方式来应用它时间等等。这就是密码哈希函数如何工作的原因，如 bcrypt 。正确的;他们通常会产生一个字符串分隔，所以他们可以确定使用的散列系统和工作因素;你只需要存储字符串而不需要知道这一点。

---

您可以在表格中以'纯文本'存储salt。

• 盐不需要保密是有效的




• 它只是随机的。


ul>



盐会加强ma的密码在同一数据库或其他数据库中将哈希值与相同密码无法比较，并且使大量预先生成的公共密码列表失效以进行哈希查找（例如， '彩虹桌'）。



因此，每个用户的salt是唯一的，并且是随密码一起存储的一些随机值;在问题中概述的替代方案（使用用户名作为salt，对整个应用程序使用单一salt值）均失败：





• <如果系统使用用户名或其他琐事，那么可以将密码与其他系统中具有相同名称的其他用户进行比较（想象'管理员'或'root'用户帐户在不同系统中使用相同密码的频率...）
如果系统对同一系统中的所有用户使用单一随机盐，那么偶然有相同密码的两个用户将具有相同的散列，并猜测一个用户的密码会微不足道的破坏另一个。




My understanding is that a salt is not intended to be secret, it is merely intended to be different from any centralized standard so that you can't develop a rainbow table or similar attack to break all hashes that use the algorithm, since the salt breaks the rainbow table. My understanding here might not be completely correct, so correct me if I'm wrong.

In a widely-used piece of open-source software, the salt would be widely known, and this opens you up to attacks because now they can simply attack the salted version of your hash and create rainbow tables that include the salt data.

As I see it, there are two options to deal with this. The first is to change the salt with every new version of the software, but this is no good because new versions of the software would no longer be able to test against old password hashes.

The second solution I thought of was to have a salt per password stored; in other words, each password gets a different salt. The downside is that the salts have to be associated with the password hashes in some way, probably just by sticking them right next to the password in the database. It might be even okay to use the username (it might not, though, probably usernames are too short).

My question is, is this acceptable? Is there any extra risk associated with storing the salt directly with the password it hashes? It seems to me that storing the salt in the source code is no different, so there's no security loss by storing the salt with the password.

DISCLAIMER: I'm not using this for any real life security system. In fact, I have never designed a password system of any kind. I'm just keeping myself vaguely educated about security issues.

解决方案

update: use a competent library e.g. passlib for Python.

These take care of generating a per-password salt and they use a proper hashing algorithm (its not enough to just use a cryptographic hash such as SHA1; you have to apply it in a way that makes it very slow to reverse e.g. looping 1000 or more times over it etc. This is how password hash functions like bcrypt work. Password storing libraries do all this properly; they typically produce a string that is delimited so they can determine the hash system and work factor used; you just store the string without needing to know this.

---

You can store the salt in 'plain-text' in the table.

• The salt does not need to be secret to be effective

• it just needs to be random.

The salt strengthens a password by making the hashed value incomparable to the same password in the same or other database, and invalidating large pre-generated lists of common password to hash lookups (e.g. 'rainbow tables').

So it's critical that the salt is unique per user and is some random value stored with the password; the alternatives outlined in the question (using the username as the salt, using a single salt value for the whole application) each fail:

• if systems use the user-name or other trivia, then the password can be compared to other users with the same name in other systems (imagine how often the 'administrator' or 'root' user account uses the same password in different systems...)

• if the system uses a single random salt for all users in the same system, then two users who by chance have the same password would have the same hash, and guessing one user's password would trivially compromise the other.

这篇关于可以用散列存储盐吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！