GPU-stuffed monster cracks Windows passwords in minutes Security researchers have put together a monster number-crunching rig capable of cracking strong passwords by brute force in minutes. Jeremi Gosney (aka epixoip) demonstrated a machine running the HashCat password cracking program across a cluster of five servers equipped with 25 AMD Radeon GPUs at the Passwords^12 conference …
You're rather overselling NTLM by describing it as "crypto" I reckon :-)
As I recall from whenever one of my parents forgot their password on XP it was a case of removing a single file in the System32 folder. Their profile name with an extension but I forget which (.key, .pid, .sam?).
"Cracking" XP is about as impressive as cracking a diary's padlock.
To be fair though doing that didnt crack the password or the security. You had physical access to the file system, and you just overwrote the password file. Any stored passwords, etc that the user had as 'secrets' would not have been recoverable...
If you want to prevent such techniques when someone has physical access to the system then you just turn on Bit Locker....
There is actually a registry (or Group Policy) switch in Windows that jumps up system cryptography levels, but not many people know about it or use it (outside of US gov contractors anyway). It's the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" setting. See http://support.microsoft.com/kb/811833
Though it changes a lot of encryption defaults to AES-256 and SHA1 for hashing (or triple DES on Windows XP and older) I believe you would have to change NTLM authentication separately, like has recommended at http://support.microsoft.com/kb/147706 for over 10 years... Though disabling NTLMv2 is harder to do, rather annoyingly.
This is nothing to do with the network authentication protocols, which have their own weaknesses...
It is to do with the password hashes which are stored on disk and in memory (in the case of domain logons)...
Vista upwards stores the NTLM hash only by default, earlier versions stored LM too. As the article points out, LM is trivially weak while NTLM is also pretty weak too, and both are massively weaker than the hashing used in any unix system.
The networking protocols are another amusing issue, since there is no need to actually crack the passwords anyway. If you have the hashes, then you can authenticate against NTLMv2 and all earlier versions without knowing the plaintext (google: pass the hash).
It's also possible to man in the middle the network auth protocols (google: metasploit smb_relay).
And there are plenty of ways to obtain the hashes, you can pull them from disk, for domain logins you can pull them from memory (the plaintext is also typically stored in memory - google for mimikatz) when a user (or service account - very common for service accounts to be logged in to all kinds of machines, even with admin privs) is logged in... So your windows domain is only as secure as its very weakest member.
I found this http://davenport.sourceforge.net/ntlm.html which says:
"While newer clients support the NTLM response, they typically send both responses for compatibility with legacy servers; hence, the security flaws present in the LM response are still exhibited in many clients supporting the NTLM response"
Which I read as NTLM is better, but unless LM is turned off, it's there as well in some cases.
MSDN say to use "Negotiate" in applications so that Kerberos if supported is automatically used instead of NTLM but that NTLM "must also be used for logon authentication on stand-alone systems".
Don't mix up network negotiation with the SAM file (i.e. local password repository). I've read nothing in this article to indicate this relates to network negotiation.
The SAM file historically (it's disabled in newer versions of Windows) stores the password in two formats, the old LM format is the one that splits the password into two columns, not NTLM.
Well salt doesn't make it harder to crack at all, it just means your rainbow tables are useless.
As for how long to crack SHA-512....
Well a post on stack overflow puts it at 10^128 years, if your using a standard "desktop" - while this machine is designed specifically for these kinds of attacks, it still in no way puts a dent in the time taken to brute force a SHA-512 for now, as long as no exploits are found.
~(All figures are off the top of my head/off random pages on the net).
The time taken depends primarily on how many possible passwords have to be tried. The choice of hashing algorithm is only going to change the answer by a smallish constant factor, unless you choose a hash function that is fantastically hard to compute, which SHA-512 isn't. (You could specify that your hash function is SHA-512 applied one million times in succession, but in practice nobody does that.)
I read it more as a warning against password reuse & repetition than as a result of a direct attack on your own network. Granted, if someone has access to stored hashes on your network you have a problem larger than their ability to decrypt said hashes, more to the point, why would they even bother looking at them if you're the actual target of the attack? However, if one of your users has their work email and their work password as the login for that specialist Russian film archive they're fond of...
Password hashes are often stolen as a result of sql injections. So the attacker doesn't really have any solid access to the server, only access to the info stored in the database. So they really have to brute every hash.
If they had access to the server then they could just change the login page to log/email every password in clear text as the user logs in.
Who could possibly have thought that was a good idea? What was the reasoning behind it.
For anyone unsure of the reasoning behind - splits a 14-character password into two seven-character strings before hashing them, which means it's a good deal less secure than an eight character password - cracking two 7 digit passwords takes twice as long as cracking one 7 digit password. where as an 8digit password has all of the 7 digit passwords with each of the available characters on the end, hence there are at least 70x more and 70x longer.
Which were, in turn, probably handicapped by computational restraints present in the early 1990's.
Eh? Any machine of any era capable of running any version of Microsoft Windows had ample resources for hashing 8-character passwords. Nothing in the systems of the time excuses the braindead LM hash - certainly not "computational restraints" (by which I assume you mean "resource constraints" or similar).
Someone above made a point which seems to have been missed by most of the commentators: the old UNIX DES-based crypt(3) hash, from circa 1978, is superior to the LM hash mechanism, from c. 1990. crypt(3) is only a 56-bit hash, but LM is also restricted to ASCII, and it folds letter case - a move almost incomprehensibly stupid - so it's actually only about 43-bit. And LM is unsalted.
Moreover, Microsoft kept LM hashes around by default until Vista (GA in 2007), so they were using a known-broken, easily-crackable hash that was worse than its major competitor for nearly 30 years.
This particular demonstration isn't a new best attack against LM - Ophcrack did better on most LM hashes back in 2003, using rainbow tables. It's just another reminder that Microsoft screwed up monumentally when they created the LM authentication mechanism. Nothing about the technology of the time excuses it.
Having to set a SPN in AD for impersonation (re-vend Kerberos tickets to apply end-user access rules in n-tier scenarios) is seen as an “unacceptable risk”… but those same “consultants” were stumped by “all content is encrypted using a zero-shift Cesar cipher”
Your point is quite well made, and I agree that in isolation, there should be no problem deciding which is most secure, but quite often there are other constraints.
I suspect that many of these security consultants may have to come up with solutions that are 'good enough' while not adding significantly to the cost and complexity of the solution.
When all is said and done, the security of any environment is a compromise between risk, cost and strength, and always will be until the strongest security is also the cheapest.
Of course, if the consultants you've known only suggest NTLM+SSL, then your scorn is probably deserved.
Im of the mindset on users that we need 2-step auth. Something along the lines of a password and a DNA sample would suffice. And no not that kind of DNA sample *quit snickering in the back*, something like a pint of their blood or something each time they log on would be good. And it has the added bonus of eliminating possible holes in the network after approximately 5-6 logins.
What can I say I hate the end user.
No I'm pretty sure I spelled what I intended correctly with "snickering*"
* snickering present participle of snick·er (Verb)
Verb
1) Give a smothered or half-suppressed laugh; snigger.
2) (of a horse) Whinny.
In this case I was using the first definition of it. As much as I like you Brits I haven't fully adopted your language over here in the States.
AC icon abuse + Assuming = down vote
from wikipedia:
"NTLM version 2 (NTLMv2), which was introduced in Windows NT 4.0 SP4"
I will stop right there with my citation.
So wow. a fantastic rig can crack a over 13 year old password hash.
which has been superseeded by a new version (and many since) since NT4 SP4. in case you forgot: NT4 SP4 was the OS of choice for the Nazi's to power their enigma machines. It was also used to launch V-2's. the russians re-utilised it for their Tsjernobyl power plant. that didn't work out that great. anyway:
that's old. and now, a gigantic rig.. can crack the password hash... from before that?
oh wow. oh wow. oh wow. (to quote a great man.)
so good for you! now go crack those WinNT 4 SP3 domains!
non-news. that's what this is.
You mock, sir, but I have a Buffalo NAS (now collecting dust on my shelf) that won't accept NTLMv2 and so back in the day when I actually used it I had to degrade my other systems (Windows and Linux) to accept NTLM.
Obviously no *Microsoft* system has force the use of NTLM on me since sometime in the last millenium. Equally obviously, had the Buffalo NAS granted me full access to the FOSS software inside it then I could have fixed the problem.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
