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
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.
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.
That's great IF you can use a password that long. My bank limits passwords to 14 characters. Their system would choke on your password.
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!
(Proof: you can remember RWOLZEKBYT or "correct horse battery staple" if you have to, but you've got no prayer of remembering RWOLZEKBYTDUQLZPEJNB or Rw3L$E5KÃ(t. )
But I can easily remember "correct horse battery staple waterslide fishnet the queen bleach" - how much entropy is that?
It's The Golden Rule: "He who has the gold makes the rules."
imagine a beowulf cluster of these...
If anyone with motivations beyond that of a script kiddie is doing this, then you are already totally screwed - they can already steal all your transaction information or make their own transactions or transfer funds or do whatever they want to do as ANY UID in that system - WHY would they ruin that and post them on the web?
And if it *IS* a script kiddie, only interested in "cred" and he leaks the password hash DB on the net, then AGAIN so what, because like the GP said you are using different passwords for different sites.
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"
Would be more interesting to see the results from an attack on a SHA-512 hash of a 15 character password. Stuff like that isn't that uncommon in many web applications out there.
Nowadays, MD5 offers mostly decorative value, whenever you want something unimportant to have a more uniform look (e.G. public reference IDs for blog entries).
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
"A 14 character Windows XP password hashed using LM for example, would fall in just six minutes"
Which is nothing impressive. NTLM has a 14 char password max and pads sub-14char passwords with null. It then breaks the password into two 7 byte pieces, hashes both pieces, then concatenates the two hashes together. Using NTLM, a 14 char password at worst 2*96^7 instead of 96^14, which is a factor of 37,572,373,905,408 difference. If NTLM was properly designed, that same 14 char password would have taken 37,572,373,905,408*6min to break or 428,908,378 years.
14 char passwords are still safe assuming there isn't a huge flaw in the password storage.
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.
> 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.
Here's how to crack the password for the Win98 login: press [Esc].
Get free satoshi (Bitcoin) and Dogecoins
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
The server sends a random string of digits to the client and says "encrypt this using your hash as the key". The client does so and responds with the encrypted data. The server, since it knows what the user's hash should look like, can then duplicate the encryption function and compare the results. The server will never see the plaintext of the password, and the hash will never leave the application space on either end, and replay attacks are impossible since the random string will be different every time (and therefor the expected response will be different every time).
Not that many places are doing this currently. And not that such a system is magically foolproof, but it does eliminate the kind of attacks you are describing.
Everyone using their email for the username and the same password everywhere means one hacked site, all hacked accounts :(
Lastpass ftw
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!
Some do, some don't. I have cracked windows passwords (friend's daughter set up the computer for him and moved away). Downloading the rainbow table took longer than actually cracking it.