Slashdot Mirror
New 25-GPU Monster Devours Strong Passwords In Minutes
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."
So it doesn't matter anymore I'm using 000000 as password ....
My conclusion is to use different passwords for different things. They don't have to be that strong.
As long as the passwords are strong enough to prevent brute forcing over the _NETWORK_ they are strong enough. If you don't pick an overly stupid password then either you or the site is going to be pwned before the hackers brute-force/guess your password over the network.
If someone has hacked into the site to obtain the hashes, it's likely they can do other stuff anyway (make transactions, get your info, maybe even get the plaintext of your password), so don't waste your time making and using super long passwords.
So now that passwords as a system is officially broken, can we please move on to something better? Something that wasn't invented to allow soldiers standing watch in the middle of the night to tell their mates from their enemies, but is actually designed for computers?
And no, of course I don't have any better ideas... this is /. and I'm here to pointlessly criticise!
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
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.
This is well known and no sane people uses NTLM auth anymore, even Microsoft recommend to deactivate this authentication method. The idiots at Microsoft used a DES ECB implementation instead of CBC that anyone with two ounce of crypto knowledge would choose. The practical impact of this very bad design choice is that a 14 character password has as much complexity as two independant 7 characters passwords ! So when the authors brag about cracking a 14 character password in 6 minutes, what they're really doing is cracking two 7 character passwords in 6 minutes, this is entirely different and not impressive at all.
http://www.transparency.org
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."
If you were blocking sigs, you wouldn't have to read this.
For comparison, the password to an account I use fairly often is 128 characters.
That must be annoying to type in every time.
More seriously, if that's a password but the system in question is only storing a relatively short hash of it, all the attacker has to do is find something that hashes to the same thing. That's pretty simple to do if you've got the grunt compute power, as there's usually no other checks on the sense of a password at the point of use (which isn't the same as the point of definition). In effect, you're not hindering attackers at all but you are making things worse for yourself. Congratulations on your addition to Security Theater! With thinking like that, you're almost qualified to work for the TSA...
(Myself? I disable logins with passwords wherever I can. Turn up with a cryptographic key — the verification of which is not a hashing operation at all — or don't turn up at all.)
"Little does he know, but there is no 'I' in 'Idiot'!"
I was under the impression that a 14 character NTLM password was basically two 7 character passwords, and the fact you can crack them easily is not news. Rainbow tables will crack them in a matter of seconds on a standard PC setup.
This isn't about live attacks on a system. This is about "offline" attacks and even things like hash collisions (where someone can make a certificate or a download that has the same hash as the "official" one but is fake or contains malware, etc.).
If you can take a login system and run millions of queries against it, it's a stupid system. But if you can steal a hashed file of password, or old hashed tokens from the network, then you can theoretically break them now in the time it takes to reboot the computer (if you could log into this other system remotely).
Things like the Sony break-in would reveal everyone's password, not just the other stolen details. And on a local network, you could sniff tokens sent for NTLM services etc. and start impersonating other users before it could even be detected. Of course you have to have a certain level of compromise / access already to get to that stage, but it doesn't make it any less dangerous to be able to forge hashes or find out their plain-text.
Please note, also, that things like these hashes have been used historically to verify software is genuine, as part of encryption algorithms, random number generators and all sorts of other things. At the time, they were reasonably unbreakable, but now they aren't. And that breaks lots of things if they are still relying on them.
Impact to security-conscious users: Zip.
Impact to security-unconscious users: Huge.
I'm really low on porn at the moment and hit my monthly internet quota!
Umm ...
/etc/shadow of a known password, sync the file systems to disk and reboot.
mount the SunOS disk, write a new password hash into
Does not take anywhere near a month!
imagine a beowulf cluster of these...
If passwords are getting cracked so quickly these days, what then is the answer? Authenticators are all well and good, but I don't have room on my keychain for one for Blizzard (I know about and have the one for my iPhone), one for Amazon, one for PayPal and eBay, one for Gmail, etc and so forth.
What would be a viable solution then?
-- Wiccan Army, 13th Airborne Division "We will not fly silently into the night"
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
md5sum
d41d8cd98f00b204e9800998ecf8427e
> You're propagating security through bogosity.
And flagging this:
http://www.schneier.com/crypto-gram-9902.html
Snake Oil Warning Signs
Warning Sign #5: Ridiculous key lengths.
Also FatPhil on SoylentNews, id 863
There problem is there is still tons of old sites that have MD5 storing passwords. Then there is the second problem of password reuse. Username/Password reuse is the more dangerous of the two, because it can render an account on a system with strong passwords where then local attacks can be attempted.
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.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!