• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

GPU - ie Radeon 5770 makes even 15 character password unsafe to brute force!

Your password is 14 characters long and has 24,613,418,037,863,089,530,994,688 combinations.

Not too worried.
 
I bet they're not even using NTLM strength encoding for passwords, unless the default setting has changed with more recent versions of Windows Server.

If it's actually LM (Lanman) strength encoding, then any password less than 7 characters can be cracked very quickly. I crank it up to NTLMv2 wherever I can, it's significantly better (though still not ideal).
 
I think it's a good demonstration however of just what these GPUs are capable when compared to traditional CPUs. I'm sure there are secret places with lots and lots of GPUs setup to do stuff like this that will dramatically cut down the time to crack hashes. I'm all for seeing just where else we can benefit from our powerful GPUs.
 
I wouldn't lose any sleep over this. Never is NTLMv2 mentioned, which superseded NTLM long, long ago. Vista and 7 don't use anything other than NTLMv2 by default.
 
You don't check passwords against whatever you are trying to login to. You check them offline against a hash.

Instead of just attempting to connect to an access point trillions of times for a WPA password. You collect the handshake and start bruteforcing it from there. You don't have to send even 1 packet to obtain the password.
 
You don't check passwords against whatever you are trying to login to. You check them offline against a hash.

Instead of just attempting to connect to an access point trillions of times for a WPA password. You collect the handshake and start bruteforcing it from there. You don't have to send even 1 packet to obtain the password.


Ah OK. So is there a way to prevent that, some method doesn't allow the attacker to brute force a hash?
 
Salted, multiple hashes.

Basically, hash it once, add "random" data (salting), hash it again, salt it again, hash it again, etc etc etc. Then, once you've done that a thousand times, then store that hash as your login key. Without detailed knowledge of the hashing + salting technique, it's basically impossible to do an offline attack, as the the attacker has no idea what kind of salting/hashing procedure was used against the password.

Not to mention it would not be as computationally trivial, so that even if someone knew the hash/salt algorithm, it would require a thousand+ times longer to generate each attack, reducing the attack speed considerably.
 
Could always use a pass phrase. Throw a number and character in there and conceivably you can get something that'll be secure long after the warm death of the universe.

The only problem is that many sites or applications limit the length of the password to some arbitrarily low and stupid number of characters such as 8.
 
Isn't there an easy solution? Require 1 or 2 seconds between login attempts.

LOL... if it was this easy, then i dont think people would bother to hack.

Easier is 5 mistakes and the account is locked. Long password and maximum mistakes. It doesnt even need to be a full lockout, could just be a 15 minute break.

no because ben told us it doesnt work like that..

Once again:

You don't check passwords against whatever you are trying to login to. You check them offline against a hash.

Instead of just attempting to connect to an access point trillions of times for a WPA password. You collect the handshake and start bruteforcing it from there. You don't have to send even 1 packet to obtain the password.

^ The way ben describes, you dont even need to access the login server until you already cracked the pw.

And the only way to protect yourself is:
Salted, multiple hashes.

Basically, hash it once, add "random" data (salting), hash it again, salt it again, hash it again, etc etc etc. Then, once you've done that a thousand times, then store that hash as your login key. Without detailed knowledge of the hashing + salting technique, it's basically impossible to do an offline attack, as the the attacker has no idea what kind of salting/hashing procedure was used against the password.

Not to mention it would not be as computationally trivial, so that even if someone knew the hash/salt algorithm, it would require a thousand+ times longer to generate each attack, reducing the attack speed considerably.

Meh... what about just getting a Apple? 😛
 
Meh... what about just getting a Apple? 😛

What does that have to do with anything? If you're still using a wireless network to connect to the internet or some other form of data transfer that's vulnerable to interception, changing your operating system doesn't change the problem at all.

Ideally, the best way to be safe is to use a separate password for everything. Failing that, the best solution is to use at least two different passwords such that if somehow your password for a forum was compromised, that the attackers couldn't gain access to your email, bank, etc. with it. Depending on every single site to implement good security practices such as multiple-hashing really isn't viable since it only takes one weak site to compromise your password which can easily be reused elsewhere.
 
You don't check passwords against whatever you are trying to login to. You check them offline against a hash.

Instead of just attempting to connect to an access point trillions of times for a WPA password. You collect the handshake and start bruteforcing it from there. You don't have to send even 1 packet to obtain the password.

so how is somebody getting the hash? What's the difference between guessing the hash versus guessing the pw itself?
 
so how is somebody getting the hash? What's the difference between guessing the hash versus guessing the pw itself?

hashes are often stored on servers' hard drives, gaining read only access can get you hash value.

common fight against this is to hash the hash with different hash function.
 
Steve Gibson wrote a great article/sample program for this exact problem. Check it out here:

http://www.grc.com/haystack.htm

Basically, it doesn't matter how complicated you password is. It only needs to have a non-dictionary word that includes a lowercase letter, an uppercase letter, a number and a symbol, and then be as long as possible. You could even use a memorable sequence as long as it includes all of those factors.
 
so how is somebody getting the hash? What's the difference between guessing the hash versus guessing the pw itself?

If the computer containing the user database is broken into, a hacker gains access to that database. At this point they have some information about your account, such as the login name and password, which is usually not stored in plaintext, but occasionally is. If it isn't in plaintext, it's probably stored as a hash.

In order to generate a hash you take a string of characters (which are decomposed into a numeric representation) and input it into a complex mathematical function that spits out a new number (the hash) of whatever you fed into it. This means in order to guess the hash you need to know how it was generated, which can be difficult as there are many mathematical functions that can be used to produce hashes along with other techniques that make it difficult to do this. Also, many of these functions are one-way, meaning that even if you have a hash, you can't use that to produce a valid input for the function that would result in that hash.

This means it's much easier to brute force the password as a large number of people use very insecure passwords that can be quickly cracked.
 
Back
Top