New 25-GPU Monster Devours Strong Passwords In Minutes 330
chicksdaddy writes "A presentation at the Passwords^12 Conference in Oslo, Norway (slides), has moved the goalposts on password cracking yet again. Speaking on Monday, researcher Jeremi Gosney (a.k.a epixoip) demonstrated a rig that leveraged the Open Computing Language (OpenCL) framework and a technology known as Virtual Open Cluster (VCL) to run the HashCat password cracking program across a cluster of five, 4U servers equipped with 25 AMD Radeon GPUs communicating at 10 Gbps and 20 Gbps over Infiniband switched fabric. Gosney's system elevates password cracking to the next level, and effectively renders even the strongest passwords protected with weaker encryption algorithms, like Microsoft's LM and NTLM, obsolete. In a test, the researcher's system was able to generate 348 billion NTLM password hash checks per second. That renders even the most secure password vulnerable to compute-intensive brute force and wordlist (or dictionary) attacks. A 14 character Windows XP password hashed using LM for example, would fall in just six minutes, said Per Thorsheim, organizer of the Passwords^12 Conference. For some context: In June, Poul-Henning Kamp, creator of the md5crypt() function used by FreeBSD and other, Linux-based operating systems, was forced to acknowledge that the hashing function is no longer suitable for production use — a victim of GPU-powered systems that could perform 'close to 1 million checks per second on COTS (commercial off the shelf) GPU hardware,' he wrote. Gosney's cluster cranks out more than 77 million brute force attempts per second against MD5crypt."
MD5? Windoze XP? INSECURE LEGACY!! (Score:1, Informative)
Who gives a rat's ass about such golden oldies? It's been possible for the longest time to fairly quickly crack windoze passwords (if you have the file) and MD5 has been known to be insecure for quite some time already...
So newer hardware is faster than older hardware. Who would've thunk?
Re:Lockout? (Score:5, Informative)
that's not the context this sort of thing works in.
passwords are stored as hashes. for example of you log into a terminal you don't want the terminal sending your pass over the network.
So it pulls down a list of hashes and compares it to the hash of your password. or it hashes your password and sends it over the network.
The idea is that someone picks up these hashes and then brute forces them at home.
not that they keep trying to log into your account one attempt at a time.
Re:Lockout? (Score:2, Informative)
That doesn't work for systems with password files. Once a system's password file (which includes the hashed passwords) is compromised, then the password programs just compare their generated hashes against the file.
We had an old ATM testing machine that ran a dinosaur version of x86 SunOS and didn't have the root password. We were able to use a FreeBSD CD to mount and recover the shadow password file and used John the ripper to crack the passwords. Ran it for a month on a dual processor 8GB rackmount.
Ob "correct horse battery staple" (Score:5, Informative)
A customer asked us recently if we could recover some of their passwords stored (hashed) on our system.
"Sure we can, if you used really poor passwords."
Re:Use different passwords for different things (Score:5, Informative)
But the issue is not brute forcing over the network. The issue is hackers stealing a database of passwords, then bruteforcing the lot of them locally. Some sites don't even bother to hash the password at all and some don't salt them or use a weak hash. So if the database is lifted, the hackers could potentially recover some or all of the passwords with little or no effort. So if you use the same email and password for an insecure site as a strong site, you are trouble.
Therefore it would be wise to arrange sites into tiers of importance. Tax / health / social security on the top. Then banks. Then cloud / email services. Then stores. Then sites with personally identifying info. Then forums and other throwaway crap. For each tier take appropriate measures to ensure uniqueness of the password and login id and use password safe to manage this mess. On the bottom tier, you could probably use the same throwaway password for every site, or a variant of it (e.g. tack on the first 4 letters of the domain host) since a compromise is a nuisance rather than as a threat.
And use something like Password Safe so you don't have to remember all this crap.
Re:Use different passwords for different things (Score:5, Informative)
I keep my Keypass database in Dropbox. That way it's synched to all my machines, or I can download it to my phone, or access it via a web browser.
Re:...and what? (Score:4, Informative)
That isn't exactly how rainbow tables work. In fact colliding chains is undesireable for rainbow tables. While it is true that you might end up on another "chain" the odds of that are exceedingly low with even 128bits of hash space and any decent salt.
The reason for itterating a password hash it to slow it down, to try and thwart brute force, however it doesn't work that well against GPUs since they have so many cores to work with and VERY efficient implementations of the algorithms. Some password hashing algorithms (I believe bcrypt is of this sort) can be tuned to take more memory and, this, keep GPUs from working much if any faster than a normal CPU. This, really, needs more research but the principals are simple: make memory access patterns impossible to predict so you can't stream in cache lines and make the space required "large" (lare isn't HUGE, I think a few megs is large enough. You won't find this in a normal cryptographic hash as they are *designed* to be fast, and that is a good thing for every use aside from this)
Rainbow tables work in chains, as you said, but what they do is they generate a hash from a "seed" for each chain THEN they "map" that hash back into the password space, and then hash that, map, hash, map, hash, da da da. Once you do this for a good long ways you store the final hash and the seed for this chain. You have MANY chains.
To find a password from the hash you pick up right in the middle of that. Lets go step by step:
You have a hash to reverse
1) check the hash against your "end of chain" hashes
2) If the hash has no match you do the same "mapping" that you did while creating the rainbow table into the password space
3) repeat until you find an "end hash" and therefore the chain, or you find that this password isn't in your table by mapping-hashing more times than you used for the chains
4) assuming you found the end hash you then take the "seed" for that chain and start hashing and mapping it over and over until you find your original hash
5) the password that you hashed to get there will be the correct one
So, yeah. Lots going on and many subtle problems that can creep in, but the chances of a collision due to itterated hashing aren't large. Smaller than anything you'll ever need to worry about. Like I said, too, itterated hashing doesn't help much against GPUs
Re:MD5? Windoze XP? INSECURE LEGACY!! (Score:2, Informative)
Exactly, using rainbow tables located on an ssd a 14 digit LM password can be cracked in under 30 seconds. Now if you instead have a 15 digit password which invalidates the stupid LM hashing algorithm (or you just turn off LM hash generation, but that can break things) then breaking the resulting password is going to take a good long while, 72^15 is a big number.
Re:Use different passwords for different things (Score:3, Informative)
Or, as a developer, just limit the number of tries per second to 1. Easy to implement, no need to lock out anyone or ban anyone or even engage tech support at any point. And the cracker can have a million GPUs - doesn't matter. They'll only be allowed to operate with the speed of a 1970s calculator.
Re:my password (Score:5, Informative)
To all you gloom and doom people out there, here's my suggestion. If your password is monkeys1459, change it to monkeys1459monkeys1459. That's 22 letters and equally memorable.
You are assuming that the password test function doesn't text the pattern XX i.e. the same string repeated.
Password crackers actually test a number of permutations, like adding every digit 0-9 to the end of the string, reversing the order of characters, setting the first letter to uppercase, setting all the letters to uppercase, AND, repeating the password.
So your little "trick" is already outsmarted by today's password crackers.
Re:MD5? Windoze XP? INSECURE LEGACY!! (Score:5, Informative)
Who gives a rat's ass about such golden oldies? It's been possible for the longest time to fairly quickly crack windoze passwords (if you have the file) and MD5 has been known to be insecure for quite some time already...
Yes and no.
LanMan hashes have been brute forceable for a long time but neither proper NTLM nor NTLM2 have, so hacker have had to "trick" clients into sending the LanMAN hash, or recovering it from the SAM file.
Another trick that is often used to secure the password is to simply not support LanMan.
one little known fact discovered by Urity of SecurityFriday.com is that if a password is fifteen characters or longer, Windows does not even store the LanMan hash correctly. This actually protects you from brute-force attacks against the weak algorithm used in those hashes. If your password is 15 characters or longer, Windows stores the constant AAD3B435B51404EEAAD3B435B51404EE as your LM hash, which is equivalent to a null password. And since your password is obviously not null, attempts to crack that hash will fail.
So, yes and no, security consious companies have been able to protect themselves from brute forceable passwords for over 10 years.
Re:my password (Score:2, Informative)
Re:MD5? Windoze XP? INSECURE LEGACY!! (Score:5, Informative)
No and no...
If a windows box is trying to connect to you (ie single sign on so it tries to auth to you), you don't need to trick it into sending the lanman pass, you can just reflect it back (google: metasploit smb_relay). But your talking about the network level NTLM, not the hash stored on disk. You can indeed try to brute force the NTLM challenges, if you wanted to.
You can brute force NTLM hashes (the disk stored kind) easily, the hashing itself is very weak compared to anything used on unix for many years.
On the other hand, you can exploit a design flaw in the aforementioned network authentication protocols which let you use the hash for authentication (google: pass the hash) - that is you don't need to bother cracking it at all, just use it.
As for where you get hashes....
Backups.
Local admin hashes on workstations etc (usually they are all the same on a large organisation)
From memory when users are logged in which includes service accounts (google: gsecdump) or you can even extract the plaintext (google: mimikatz)
Typically you only need to find a single insecure system and you will be able to compromise an entire domain within minutes, even when most machines are fully updated and/or hardened.