Topic: Basic Questions About Brute-Force Attacks (Read 1242 times)

Tnx ;-)

FTFY

It all depends on how strong your password is...

Some numbers: Have a look http://project-rainbowcrack.com/table.htm at the bottom of the page where it says "md5_ascii-32-95#1-8". A table with with all passwords with a length of 1-8 characters in the complete ascii space is around 600GB. The longer your password is, the bigger the table needs to be... and this also needs to be generated.

That's also why you need to hash your passwords if you store them. The rainbow table needs to be generated with the hash that's used on the site...

I have just read this http://www.dailytech.com/Inside+the+MegaHack+of+Bitcoin+the+Full+Story/article21942.htm

Here or my thoughts. This will be a long post. Text that I have taken from that article will look like this, "Article Quote".

...On Monday at around 5 pm, 25,000 bitcoins were transferred into account "1KPTdMb6p7H3YCwsy FqrEmKGmsHqe1Q3jg".  The coins in question came from 25,000 accounts.  Given recent trading values, that would indicate the counts were worth somewhere between $375,000 and $500,000 USD...

If true, then 25,000 accounts have been robed. I have not been paying attention to this. Had all of the users (not just the ones that have been hacked) been notified at the first sign of these attacks? If not, then this is bad business. Well they are not the only ones. Remember Sony anyone?

I have read that Banks have been hacked and the only way that people found out was when it was reported IN THE MEDIA. Sad, sad sad.

Users can not do much if a company does not value security. This means that the end users have to do the best they can for security on their side. This includes strong passwords and virus scans as a minimum. Protect yourself as best as you can, because companies are not doing it.

...Mt. Gox's support team...Responding to commenters...As I already replied...we assume no responsibility should your funds be stolen by someone using your own password...

They assume no responsibility, even if they made it easier for the hack with their poor security. Protect yourself people.

...Leaked information includes username, email and hashed password...

No information how the information was leaked? If they don't know, then how can they say that it will never happen again.

Did they say that it would never happen again? Not yet? Then it is coming (my guess).

...used a simple password you will not be able to login on Mt.Gox until you change your password to something more secure...

This statement really upsets me. Yes, I think they could do it.
One way is to use a rainbow table (I'll explain that below). No company I know of has done that.

What upsets me is why don't they do that when you are signing up (the first time). e.g., When signing up: You will get a prompt similar to,  "Sorry. Your password has been determined to not be very secure. For your protection, you will have to choose another one.

Or at least, "Your password is weak and can be easily hacked, do you really want to use it? 

...If you used the same password on different places, it is recommended to change it as soon as possible...

Outstanding advice. No one should use the same password for other sites. Use a password manager to help with this. KeePass have been mentioned in this forum before. I have suggested LastPass. Pick one and use it. It is for your protection. Just Google KeePass or LastPass for more info.

...According to MagicalTux Mt. Gox's current protection scheme was to use and MD5 hash on passwords in its database, along with a salt...

MD5??? Say it isn't so. It could have been worst. It could have been in plain text (i.e, no protection at all). Sony anyone.
Don't get me wrong, I don't think anything is wrong with MD5 even though it has been comprised (however I'm not a security expert). I do know that are other algorithms that more powerful. Why not use one of those?

What is a hash? When you hash something, you are putting it through an algorithm (i.e, a program) and getting an fix length output.
Here is my understanding of the 3 things a good hash algorithm has.

(1) It will provide the same unique fixed length (output) result for a file (input).
e.g., You put 123456 into MD5 and you get e10adc3949ba59abbe56e057f20f883e
If you put in 1234567 you get fcea920f7412b5da7be0cf42b8c93759

With MD5, you get a 32 digit outcome. It doesn't matter if the input is 1 digit or 1 million digits. For MD5, the outcome will be a 32 digit outcome. This is important (for me at least) because if a site tells you that there is a maximum length for a password, then that could mean that they are not hashing your password. Be warned.

Other algorithms will also have a fixed length. The length is depended on the algorithm. 

Because of these unique hashes, people will call a hash as a digital fingerprint of that file. So if you know the hash of a file and someone sends you that file, you can hash it. If the hash doesn't match, then you know that file is different. You will not know what or how much it was changed, however you will know it was changed.

(2) It is one way. 
You can not easily determine what the input was from a hash. In theory, at some time you will be able to do this. In practice it has not been done.

(3) It will not have any collisions.
If you hash something, then you will not get the same hash if you hash something else.
e.g. You hash x and the result is 123456789.
Someone else using the same algorithm, hashes w and get 123456789. This is a collision.
In this case, you can go into that person's account by using your password (and vice-versa).

If I remember correctly, MD5 has been proven (on some proof of concept paper with a lot of math on it  ) that it could produce collisions. In practice, it is of a small concern because it is very difficult to do. Not sure if has actually been done.

Things to keep in mind.  You can not determine what the password is from a hash (see 2 above), however you can put a known password into a hash and take a note of that hash. If you do this with with a lot of passwords and put the results into a database, then you have a rainbow table. e.g., You put hash 1234 (the most popular password) with MD5 and get 81dc9bdb52d04dc20036dbd8313ed055. Then somehow you get a hold of a database and you see 81dc9bdb52d04dc20036dbd8313ed055 on the list. No need to bruteforce that one. The password is 1234. Hopefully nothing was important in that account, because you just made it easy for the hacker.
 
To make it harder, some companies (all of them should) will add a salt to your password. A salt should be a long string of random data. Let's assume that the salt is 81dc9bdb52d04dc20036dbd8313ed055. So when you put in your password (1234) the salt is added to it. In this case we will say that the salt is added to the end of your password.

So password + salt =123481dc9bdb52d04dc20036dbd8313ed055: The site will hash that and will get (still using MD5) 1113183d7dc42beec92b6a393230db4b. So if 1113183d7dc42beec92b6a393230db4b is not in their table, then bruteforce time. There are hash calculators available free for download and online.

Want to do something fun. Download a hash calculator. Play with it to so know how to use it. Then goto http://md5.gromweb.com/ That site is an online rainbow table for MD5. Then put 1234 in the calculator. The result in MD5 is 81dc9bdb52d04dc20036dbd8313ed055. Put that result into the online rainbow. It came back 1234. Cool. Now put your password into the calculator. Use the MD5 result and put it into the rainbow.

Did your password come back? If so, CHANGE THAT PASSWORD NOW. That rainbow says it (only) has 46,201,686 MD5 reverse hashes.

...approximately 1,600 passwords appear unsalted.  Cracking unsalted MD5 hashes is a pretty elementary task with rainbow table or brute force attacks....

I wouldn't call that cracking. With 1,600 passwords, it would take a computer less then a second (my guess) even with a large rainbow.  I could be wrong.

Any crackers want to enlighten us on this?

Essentially any brute force client (GPU, CPU, whatever) will run billions of iterations of this:

1. Generate string
2. Grab salt (usually part of the input, at least in the case of the FreeBSD MD5 that Mt.Gox used)
3. Run crypt(string, salt), which in the FreeBSD implementation actually hashes about 1000 times
4. Check if output is expected output.
5. Repeat the above.

The nice thing about the salted FreeBSD-style MD5 is that it is pretty computationally expensive to run.  High-end GPU setups only manage about 3 MH/S, and CPUs about 12 KH/S per thread (I managed 48KH/s on an overclocked i5 750).  This slows down potential crackers considerably.   At 48KH/s, you can expect an 8-char password containing all possible characters (num, letters, specials) to take some 2.93*10^12 years.  On a GPU it is orders of magnitude better but still on the order of years.

It is very likely that the major account that was hacked was only compromised because it had its password encrypted using the old DES encryption Mt.Gox used to use until 2 months ago.  If that password was retrieved at any point and not changed it would be easily used to wreak havoc.

thanks for that desc.

If they have the hashed password from the user database they verify it the same way the website does when you try to log in.

They run the guessed password through an algorithm and compare the output to the value from the database. If they match, the password will work to log into the website.

but in an offline attack how do they know they got the right answer ? (ie cracked it)

re brute force 
It still takes time to break offline if you have a strong password and still takes a bit of  time even if you don't. Changing passwords to things like online banking and investment accounts regularly is second nature to a lot of us and often I've chosen where I'm willing to do business simply by whether or not they support strong passwords and enforce a change policy. To me, that means they are serious about helping protect me.

There are online attacks and offline attacks.

In an offline attack, the password file might be downloaded and can then be brute forced without any of the restrictions set by the login page.

What happened with Mtgox was someone dumped a database snapshot of username, email, and passwords. You can easily brute force those offline.

If a site gets hacked and someone makes off with the password file(s), then you can use a brute force attack on it. Trying to brute force a password on a website would essentially be a DoS (denial of service) on that login page. You would crash the server before you got in the account. And any website that would let someone try password after password is poorly designed.

If you are referring to the Gox stuff.  To brute force the passwords they have, they will do that offline I think.  But I am no experience haver myself.

Also these miners these days have some pretty crazy rigs that do some nasty computing pretty fast, so I think password cracking by brute is a way to get things done again.

Do websites actually allow the same user to try to log on a zillion times per minute, like a brute-force attacker would?  Wouldn't a short login delay or a captcha stop all website-based brute-force attacks?  And if so, why wouldn't every website have this?

Another thing I don't get:  Some people point out how easy it is to crack the hash of a weak password.  But, to get the hash in the first place, wouldn't a website have to be broken into first?

The one area I could see a brute-force attack as being very effective is when the attacker has a password-protected file on his computer (e.g. an encrypted zip file).  Since it's on his computer, he can attack it at lightning speed with no obstacles like login delays or captchas.

Would someone with more experience please help me understand this?  Thanks.