密码盐如何帮助防止彩虹表攻击？ [英] How does password salt help against a rainbow table attack?

问题描述

我有一些麻烦理解盐的目的为密码。这是我的理解，主要用途是阻止彩虹表攻击。但是，我已经看到实现这个方法似乎并不真的使问题更难。

我看到很多教程建议盐被用作以下：

  $ hash = md5（$ salt。$ password）
  

推理是，哈希现在不映射到原始密码，而是映射密码和盐的组合。但是 $ salt = foo 和 $ password = bar 和 $ hash = 3858f62230ac3c915f300c664312c63f 。现在有一个彩虹表的人可以扭转哈希，并提出输入foobar。然后，他们可以尝试所有的密码组合（f，fo，foo，... oobar，obar，bar，ar，ar）。可能需要几个毫秒才能获得密码，但是没有其他的。

我看到的另一个用法是在我的linux系统上。在/ etc / shadow中，哈希密码实际上存储在 盐。例如，foo的盐和bar的密码将散列为： $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 。如果一个黑客能够得到他的手在这个文件，我不知道盐服务的目的，因为 te5SBM.7C25fFDu6bIRbX 的反向散列已知包含

感谢任何人可以在这里散发光。

strong>：感谢您的帮助。为了总结我的理解，盐使得哈希密码更加复杂，从而使它不太可能存在于预计算的彩虹表中。

解决方案

公共盐将不会在打开单个密码时更难进行字典攻击。正如你所指出的，攻击者可以访问哈希密码和盐，因此当运行字典攻击时，她可以尝试破解密码时使用已知的盐。

公共salt做两件事情：使得破解大量密码列表更加耗时，并且使用彩虹表是不可行的。

要理解第一个，想象一个单一的密码文件，包含数百个用户名和密码。没有盐，我可以计算md5（attempt [0]），然后扫描文件，看看这个哈希是否显示在任何地方。如果存在盐，则我必须计算md5（salt [a]，attempt [0]），与条目A比较，然后是md5（salt [b]。attempt [0]等等。现在我有 n 倍的工作量，其中 n 是包含的用户名和密码数

要理解第二个，你必须了解彩虹表是什么。彩虹表是常用密码的预计算哈希的大型列表。再次想象一下没有盐的密码文件。所有我要做的是通过文件的每一行，拉出哈希密码，并在彩虹表中查找。我从来不必计算一个散列。如果查找比哈希函数（它可能是）快得多，这将大大加快破解文件。

但如果密码文件被盐化，那么彩虹表将必须包含salt，password预先哈希。如果盐是充分随机的，这是不太可能的。我可能在我的常用的，预先哈希的密码（彩虹表）列表中有像hello和foobar和qwerty，但我不会有像jX95psDZhello LPgB0sdgxfoobar或dZVUABJtqwerty预先计算。这将使彩虹表过于庞大。

因此，盐将攻击者减少回每次每行一次的计算，一个足够长，足够随机的密码，（一般来说）是不可破解的。

I'm having some trouble understanding the purpose of a salt to a password. It's my understanding that the primary use is to hamper a rainbow table attack. However, the methods I've seen to implement this don't seem to really make the problem harder.

I've seen many tutorials suggesting that the salt be used as the following:

$hash =  md5($salt.$password)

The reasoning being that the hash now maps not to the original password, but a combination of the password and the salt. But say $salt=foo and $password=bar and $hash=3858f62230ac3c915f300c664312c63f. Now somebody with a rainbow table could reverse the hash and come up with the input "foobar". They could then try all combinations of passwords (f, fo, foo, ... oobar, obar, bar, ar, ar). It might take a few more milliseconds to get the password, but not much else.

The other use I've seen is on my linux system. In the /etc/shadow the hashed passwords are actually stored with the salt. For example, a salt of "foo" and password of "bar" would hash to this: $1$foo$te5SBM.7C25fFDu6bIRbX1. If a hacker somehow were able to get his hands on this file, I don't see what purpose the salt serves, since the reverse hash of te5SBM.7C25fFDu6bIRbX is known to contain "foo".

Thanks for any light anybody can shed on this.

EDIT: Thanks for the help. To summarize what I understand, the salt makes the hashed password more complex, thus making it much less likely to exist in a precomputed rainbow table. What I misunderstood before was that I was assuming a rainbow table existed for ALL hashes.

解决方案

A public salt will not make dictionary attacks harder when cracking a single password. As you've pointed out, the attacker has access to both the hashed password and the salt, so when running the dictionary attack, she can simply use the known salt when attempting to crack the password.

A public salt does two things: makes it more time-consuming to crack a large list of passwords, and makes it infeasible to use a rainbow table.

To understand the first one, imagine a single password file that contains hundreds of usernames and passwords. Without a salt, I could compute "md5(attempt[0])", and then scan through the file to see if that hash shows up anywhere. If salts are present, then I have to compute "md5(salt[a] . attempt[0])", compare against entry A, then "md5(salt[b] . attempt[0])", compare against entry B, etc. Now I have n times as much work to do, where n is the number of usernames and passwords contained in the file.

To understand the second one, you have to understand what a rainbow table is. A rainbow table is a large list of pre-computed hashes for commonly-used passwords. Imagine again the password file without salts. All I have to do is go through each line of the file, pull out the hashed password, and look it up in the rainbow table. I never have to compute a single hash. If the look-up is considerably faster than the hash function (which it probably is), this will considerably speed up cracking the file.

But if the password file is salted, then the rainbow table would have to contain "salt . password" pre-hashed. If the salt is sufficiently random, this is very unlikely. I'll probably have things like "hello" and "foobar" and "qwerty" in my list of commonly-used, pre-hashed passwords (the rainbow table), but I'm not going to have things like "jX95psDZhello" or "LPgB0sdgxfoobar" or "dZVUABJtqwerty" pre-computed. That would make the rainbow table prohibitively large.

So, the salt reduces the attacker back to one-computation-per-row-per-attempt, which, when coupled with a sufficiently long, sufficiently random password, is (generally speaking) uncrackable.

这篇关于密码盐如何帮助防止彩虹表攻击？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！