The wikipedia article is a bit difficult to understand. In a nutshell, you can think of a Rainbow Table as a large dictionary with pre-calculated hashes and the passwords from which they were calculated.
The difference between Rainbow Tables and other dictionaries is simply in the method how the entries are stored. The Rainbow table is optimized for hashes and passwords, and thus achieves great space optimization while still maintaining good look-up speed. But in essence, it's just a dictionary.
When an attacker steals a long list of password hashes from you, he can quickly check if any of them are in the Rainbow Table. For those that are, the Rainbow Table will also contain what string they were hashed from.
Of course, there are just too many hashes to store them all in a Rainbow Table. So if a hash is not in the particular table, the hacker is out of luck. But if your users use simple english words and you have hashed them just once, there is a large possibility that a good Rainbow Table will contain the password.
It's when somebody uses a Rainbow table to crack passwords.
If you are worried about this, you should use Salt. There is also a Stack Overlow question that might help you understand salt a little better than Wikipedia...
这对于弱密码和/或无盐密码哈希最有用。 一个流行的例子是 LAN Manager 哈希，Windows XP 之前的版本都使用它来存储用户信息密码。
请注意，即使是像 LM 哈希这样简单的东西，预先计算的彩虹表也需要大量 CPU 时间来生成，并占用相当多的空间（大约 10 GB IIRC）。
Broadly speaking, you encrypt a vast number of possible short plaintext strings (i.e. for passwords), and store the encrypted values alongside the plaintext. This makes it (relatively) straightforward to simply lookup the plaintext when you have the encrypted value.
This is most useful for weak and/or unsalted password hashes. A popular example is the LAN Manager hash, used by versions of Windows up to XP to store user passwords.
Note that a pre-computed rainbow table for even something as simple as the LM hash takes a lot of CPU time to generate and occupies a fair amount of space (on the order of 10s of gigabytes IIRC).
Rainbow Tables basically allow someone to store a large number of precomputed hashes feasibly.
This makes it easy to crack your hashed passwords, since instead of performing a whole heap of hashing functions, the work has already been done and they virtually just have to do a database lookup.
The best protection against this kind of attack is to use a salt (random characters) in your password. i.e. instead of storing md5(password), store md5(password + salt), or even better md5(salt + md5(password)).
Since even with rainbow tables, it is going to be near impossible to store all possible salted hashes.
BTW, obviously you have to store your salt with your hash so that you can authenticate the user.
Late to the party but I was also aware of Rainbow Tables being a method of attack on hashed/unsalted passwords. However on Twitter recently http://codahale.com/how-to-safely-store-a-password/ was shared and depending on your needs and concerns.. you may not be able to salt your way to safe password storage.
发布评论
评论（7）
维基百科的文章有点难以理解。 简而言之，您可以将彩虹表视为一个大型字典，其中包含预先计算的哈希值以及计算它们的密码。
Rainbow Tables 与其他词典的区别仅在于条目的存储方法。 Rainbow表针对哈希值和密码进行了优化，从而在保持良好的查找速度的同时实现了巨大的空间优化。 但本质上，它只是一本字典。
当攻击者从您那里窃取一长串密码哈希值时，他可以快速检查其中是否有任何一个在彩虹表中。 对于那些，彩虹表还将包含它们散列的字符串。
当然，哈希值太多，无法将它们全部存储在彩虹表中。 因此，如果哈希值不在特定的表中，那么黑客就不走运了。 但是，如果您的用户使用简单的英语单词，并且您只对它们进行了一次哈希处理，那么一个好的彩虹表很可能会包含密码。
The wikipedia article is a bit difficult to understand. In a nutshell, you can think of a Rainbow Table as a large dictionary with pre-calculated hashes and the passwords from which they were calculated.
The difference between Rainbow Tables and other dictionaries is simply in the method how the entries are stored. The Rainbow table is optimized for hashes and passwords, and thus achieves great space optimization while still maintaining good look-up speed. But in essence, it's just a dictionary.
When an attacker steals a long list of password hashes from you, he can quickly check if any of them are in the Rainbow Table. For those that are, the Rainbow Table will also contain what string they were hashed from.
Of course, there are just too many hashes to store them all in a Rainbow Table. So if a hash is not in the particular table, the hacker is out of luck. But if your users use simple english words and you have hashed them just once, there is a large possibility that a good Rainbow Table will contain the password.
当有人使用 Rainbow 表 来破解密码时。
如果您担心这一点，您应该使用 Salt。 还有一个Stack Overlow问题可能会帮助您更好地理解salt比维基百科...
It's when somebody uses a Rainbow table to crack passwords.
If you are worried about this, you should use Salt. There is also a Stack Overlow question that might help you understand salt a little better than Wikipedia...
这是一篇针对外行人士的关于 Rainbow Tables 的有用文章。 （并不是说你是外行，但写得很好而且简洁。）
This is a useful article on Rainbow Tables for the lay person. (Not suggesting you are a layperson, but it's well written and concise.)
一般来说，您可以加密大量可能的短明文字符串（即密码），并将加密值与明文一起存储。 当您拥有加密值时，这使得简单地查找明文变得（相对）简单。
这对于弱密码和/或无盐密码哈希最有用。 一个流行的例子是 LAN Manager 哈希，Windows XP 之前的版本都使用它来存储用户信息密码。
请注意，即使是像 LM 哈希这样简单的东西，预先计算的彩虹表也需要大量 CPU 时间来生成，并占用相当多的空间（大约 10 GB IIRC）。
Broadly speaking, you encrypt a vast number of possible short plaintext strings (i.e. for passwords), and store the encrypted values alongside the plaintext. This makes it (relatively) straightforward to simply lookup the plaintext when you have the encrypted value.
This is most useful for weak and/or unsalted password hashes. A popular example is the LAN Manager hash, used by versions of Windows up to XP to store user passwords.
Note that a pre-computed rainbow table for even something as simple as the LM hash takes a lot of CPU time to generate and occupies a fair amount of space (on the order of 10s of gigabytes IIRC).
彩虹表基本上允许人们可行地存储大量预先计算的哈希值。
这使得破解散列密码变得很容易，因为工作已经完成，而不是执行一整堆散列函数，他们实际上只需要进行数据库查找。
防范此类攻击的最佳保护措施是在密码中使用盐（随机字符）。 即，不要存储 md5(密码)，而是存储 md5(密码 + salt)，甚至更好的 md5(salt + md5(密码))。
因为即使使用彩虹表，也几乎不可能存储所有可能的加盐哈希值。
顺便说一句，显然您必须将盐与哈希值一起存储，以便可以对用户进行身份验证。
Rainbow Tables basically allow someone to store a large number of precomputed hashes feasibly.
This makes it easy to crack your hashed passwords, since instead of performing a whole heap of hashing functions, the work has already been done and they virtually just have to do a database lookup.
The best protection against this kind of attack is to use a salt (random characters) in your password. i.e. instead of storing md5(password), store md5(password + salt), or even better md5(salt + md5(password)).
Since even with rainbow tables, it is going to be near impossible to store all possible salted hashes.
BTW, obviously you have to store your salt with your hash so that you can authenticate the user.
虽然迟到了，但我也知道彩虹表是一种攻击散列/无盐密码的方法。 然而，最近在 Twitter 上 http://codahale.com/how-to-safely- store-a-password/ 已共享，具体取决于您的需求和顾虑。您可能无法以安全的方式存储密码。
我希望这对您有所帮助。
Late to the party but I was also aware of Rainbow Tables being a method of attack on hashed/unsalted passwords. However on Twitter recently http://codahale.com/how-to-safely-store-a-password/ was shared and depending on your needs and concerns.. you may not be able to salt your way to safe password storage.
I hope this is informative to you.
维基百科是你的朋友：
http://en.wikipedia.org/wiki/Rainbow_table
Wikipedia is your friend:
http://en.wikipedia.org/wiki/Rainbow_table