Log in

View Full Version : Rainbow Tables and Breaking of Hashes


nbk2000
June 20th, 2005, 12:33 PM
Google for:

"rainbow tables"

and see what's happened with MD5, SHA1, and other 'secure' hashes.

Seems that, with a large enough table, you can break a 14 space windows character-set password hash in just a few minutes.

VBulletin uses MD5 for hashing the passwords, I believe.

Of course, for this attack to work, the attacker has to have the hash. But if they can get that, they can crack it locally on their machine in just a few minutes and recover the plaintext of the password, allowing them to log in as Admin or whoever.

Now, it's possible to defeat this attack by using ALT+ character codes, which significantly increase the required table size, which means many machines having to run in parallel, to accomplish table generation within a few months.

See, the tables have to be precomputed, and can take up hundreds of gigabytes, but once they have been computed, they can be stored and used for an attack, which only takes minutes.

So now I'll have to create a new password using ALT+ characters for accessing the Forum, and Mega (not mega) will have to do so to.

nbk2000
June 20th, 2005, 12:33 PM
Google for:

"rainbow tables"

and see what's happened with MD5, SHA1, and other 'secure' hashes.

Seems that, with a large enough table, you can break a 14 space windows character-set password hash in just a few minutes.

VBulletin uses MD5 for hashing the passwords, I believe.

Of course, for this attack to work, the attacker has to have the hash. But if they can get that, they can crack it locally on their machine in just a few minutes and recover the plaintext of the password, allowing them to log in as Admin or whoever.

Now, it's possible to defeat this attack by using ALT+ character codes, which significantly increase the required table size, which means many machines having to run in parallel, to accomplish table generation within a few months.

See, the tables have to be precomputed, and can take up hundreds of gigabytes, but once they have been computed, they can be stored and used for an attack, which only takes minutes.

So now I'll have to create a new password using ALT+ characters for accessing the Forum, and Mega (not mega) will have to do so to.

Nihilist
June 22nd, 2005, 05:27 AM
The solution to this problem is to use SHA-256. It's just a longer hash, that is harder to brute force. And by harder, I mean a few extra lifetimes of the universe.

Nihilist
June 22nd, 2005, 05:27 AM
The solution to this problem is to use SHA-256. It's just a longer hash, that is harder to brute force. And by harder, I mean a few extra lifetimes of the universe.

nbk2000
June 22nd, 2005, 12:20 PM
Rainbow tables don't 'Brute Force' a hash, which is what's so significant about them.

If it was just a standard brute-force attack tool, it's still take lifetimes to run, but it's not. Which is why it works in just a few minutes.

Read the white-papers about it.

nbk2000
June 22nd, 2005, 12:20 PM
Rainbow tables don't 'Brute Force' a hash, which is what's so significant about them.

If it was just a standard brute-force attack tool, it's still take lifetimes to run, but it's not. Which is why it works in just a few minutes.

Read the white-papers about it.

Nihilist
June 25th, 2005, 12:37 AM
Believe me, I have. They are what's called a "time/space trade off attack". A large number of the hashes are pre-computed, and used as references to crack the hash you are attempting to crack. However, when dealing with SHA-256, it'd take more time, and it'd take more space. Exponentially more. Making it infeasible to crack in this way.

Nihilist
June 25th, 2005, 12:37 AM
Believe me, I have. They are what's called a "time/space trade off attack". A large number of the hashes are pre-computed, and used as references to crack the hash you are attempting to crack. However, when dealing with SHA-256, it'd take more time, and it'd take more space. Exponentially more. Making it infeasible to crack in this way.

Third_Rail
June 25th, 2005, 01:33 AM
For the next few years of computing power, anyway... what about the upcoming holographic storage and the really (10ghz+) chips running 4 to a board?

Third_Rail
June 25th, 2005, 01:33 AM
For the next few years of computing power, anyway... what about the upcoming holographic storage and the really (10ghz+) chips running 4 to a board?

nbk2000
June 25th, 2005, 11:22 AM
Once the table is computed, then it's only a matter of minutes to crack a hash, regardless of how large it is.

While it's infeasible to compute a multi-terabyte table on your home computer, it'd be feasible if you had a distributed network churning the table out, something like the SETI@Home project.

It could be a volunteer program, such as Forum members, or it could be an 3LL+3 H@cK0rZ using a zombie network to compute it. Either way, once you have a table with the targets hash value in it, you have access.

nbk2000
June 25th, 2005, 11:22 AM
Once the table is computed, then it's only a matter of minutes to crack a hash, regardless of how large it is.

While it's infeasible to compute a multi-terabyte table on your home computer, it'd be feasible if you had a distributed network churning the table out, something like the SETI@Home project.

It could be a volunteer program, such as Forum members, or it could be an 3LL+3 H@cK0rZ using a zombie network to compute it. Either way, once you have a table with the targets hash value in it, you have access.

megalomania
June 27th, 2005, 04:56 PM
I thought vb uses a double encrypted hash string consisting of a hashed password encrypted by a hash. The board also uses a custom non standard implementation of MD5 to make it harder for people to apply ways that work on standard MD5.

According to the vb people the non standard implementation makes security through obscurity. Using double hashes means you have to crack both to get the password. What I don't get is how one would get the hashes to begin with? Perhaps if one had access to the database you could get the hash, but the hashes themselves are encrypted in the database. Vb is done in such a way that not even an admin can get anothers password.

If you feel it is necessary, NBK, I can increase the password length to 256 chars. It is also possible to force passwords to be changed after x days. It may also be possible to restrict staff accounts to an approved IP range, so for example I could only access The Forum from home.

I just wonder exactly how much damage a person could do if our accounts were comprimised. You can't get any other passwords. They could delete the posts, but those are easily restored by reinstalling the database. They could send everyone emails, but that is why I like to sign official mailings with my PGP key. They could get into the staff section, but we use PGP encrypted posts to talk to one another. We arn't the Pentagon, just a bulletin board :)

megalomania
June 27th, 2005, 04:56 PM
I thought vb uses a double encrypted hash string consisting of a hashed password encrypted by a hash. The board also uses a custom non standard implementation of MD5 to make it harder for people to apply ways that work on standard MD5.

According to the vb people the non standard implementation makes security through obscurity. Using double hashes means you have to crack both to get the password. What I don't get is how one would get the hashes to begin with? Perhaps if one had access to the database you could get the hash, but the hashes themselves are encrypted in the database. Vb is done in such a way that not even an admin can get anothers password.

If you feel it is necessary, NBK, I can increase the password length to 256 chars. It is also possible to force passwords to be changed after x days. It may also be possible to restrict staff accounts to an approved IP range, so for example I could only access The Forum from home.

I just wonder exactly how much damage a person could do if our accounts were comprimised. You can't get any other passwords. They could delete the posts, but those are easily restored by reinstalling the database. They could send everyone emails, but that is why I like to sign official mailings with my PGP key. They could get into the staff section, but we use PGP encrypted posts to talk to one another. We arn't the Pentagon, just a bulletin board :)

Jacks Complete
June 29th, 2005, 05:33 AM
If the NSA really want to find us all, they will.

For example, if the # of "my_pasword" was 12345678, and you knew the hashing routine (which we all do, since phpBB is open) it would be easy to look through the tables and match that, then work backwards to "my_pasword" and then the username.

However, a seed is cleverly added to the password, so suddenly and repeatably, the # becomes 45678903 instead. And you can't work backwards, since that is the nature of a one-way hash.

Remember that it is all stored in clear, except the passwords. However, if the seed for the MD5 is kept secret, this isn't a problem. A rainbow table can only work if the seed is known, as otherwise the matches would be wrong (if you ever got any) since the MD5 has been worked out on the wrong initial data.

This is, of course, assuming that the seed was changed and/or set up in the first place. Most people don't bother.

Once you have admin access to the back end of these boards (direct to the database), you don't need to worry about the passwords, since you can edit any entry or search for anything. That would be far quicker and easier to get, since most people use something like phpMyAdmin, which sends passwords in clear.

Jacks Complete
June 29th, 2005, 05:33 AM
If the NSA really want to find us all, they will.

For example, if the # of "my_pasword" was 12345678, and you knew the hashing routine (which we all do, since phpBB is open) it would be easy to look through the tables and match that, then work backwards to "my_pasword" and then the username.

However, a seed is cleverly added to the password, so suddenly and repeatably, the # becomes 45678903 instead. And you can't work backwards, since that is the nature of a one-way hash.

Remember that it is all stored in clear, except the passwords. However, if the seed for the MD5 is kept secret, this isn't a problem. A rainbow table can only work if the seed is known, as otherwise the matches would be wrong (if you ever got any) since the MD5 has been worked out on the wrong initial data.

This is, of course, assuming that the seed was changed and/or set up in the first place. Most people don't bother.

Once you have admin access to the back end of these boards (direct to the database), you don't need to worry about the passwords, since you can edit any entry or search for anything. That would be far quicker and easier to get, since most people use something like phpMyAdmin, which sends passwords in clear.

nbk2000
July 6th, 2005, 07:33 PM
just wonder exactly how much damage a person could do...

This is a question that is always answered AFTER an attacker has wreaked havoc, whether on the internet or in real life.

Better to never find out.

nbk2000
July 6th, 2005, 07:33 PM
just wonder exactly how much damage a person could do...

This is a question that is always answered AFTER an attacker has wreaked havoc, whether on the internet or in real life.

Better to never find out.