Feeds

back to article 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 in …

COMMENTS

This topic is closed for new posts.

Page:

Anonymous Coward

Shock Horror

Old crypto broken by modern hardware.

Hold the press.

22
0
Silver badge

Re: Shock Horror

Indeed. NTLM passwords are insecure. Who knew?

8
1
Silver badge
Thumb Up

Re: Shock Horror

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.

3
5
JDX
Gold badge

Re: Shock Horror

When XP was launched, how long it it take or how much would a comparable machine cost?

We're 3 versions of Windows beyond XP - the more important question is how things are different in Vista/7/8 - anyone know?

5
2
Silver badge

Re: Shock Horror

@Annihilator

If you have physical access to the disk, you're right: it's easy. Another reason to have a Linux Live CD or memory stick, always worth making one when your system is working- 'just in case'.

3
0

Re: Shock Horror

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.

13
0
Anonymous Coward

Re: Shock Horror

What an incredibly thorough and helpful post. Thanks!

3
0
Bronze badge

Re: Shock Horror

Annihilator» ...cracking a diary's padlock...

You mean reading their secure, protected facebook page, surely?

1
0
Silver badge

Re: Shock Horror

Easier still, boot into safe mode, log in as admin, (no average home user ever set admin in xp) remove user passwords...

0
1
Anonymous Coward

Shock Horror

Old Windows crypto demonstrated to be easily broken by resources the NSA would have had at the time.

Hold the press.

1
0
FAIL

Re: Shock Horror

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.

1
0
Bronze badge
Mushroom

Re: Shock Horror

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....

0
3
Bronze badge
Mushroom

Re: Shock Horror

Again though - that doesnt compromise security. An Admin user is supposed to be able to set and remove passwords...

I am pretty sure that XP forces you to set an Admin password...

0
4
Bronze badge
Mushroom

Re: Shock Horror

NTLM and reversible password hashes have been disabled by default since Vista / Server 2008.

Such attacks are now not possible unless you downgrade the default security settings. And the passwords are never in the DC memory in the default case.

0
4
Silver badge

Re: Shock Horror

I am pretty sure that XP forces you to set an Admin password...

No it doesn't. It then proceeds to allow anybody to do aything to it.

UAC was possibly the only useful feature in Vista, and they ripped off Sudo to manage it.

Then applied a patent.

1
0
Anonymous Coward

Epic Fail.

No, NTLM doesn't split the password into to, that's LM.

3
2
Bronze badge

Re: Epic Fail.

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".

2
1
Silver badge
Facepalm

Epic Fail.

"into to"

10
1
Anonymous Coward

Re: Epic Fail.

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.

0
0
Thumb Up

Re: Epic Fail.

Correct, it's LAN Manager hashes that do the split into two 7-byte components, which makes an 8-character password unusually easy to crack. NTLM superseded LanMan, and anyone who still has LanMan turned on is a muppet; it went years ago.

2
0
Headmaster

Re: Epic Fail. @Ole Juul

"into to"

You mean

"into two"

0
3

I wonder...

...how long it takes for it to break a non-dictionary based alphanumeric password hashed with SHA-512 and salt? That would be useful information.

0
0
Alert

Re: I wonder...

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).

5
0
Anonymous Coward

Re: I wonder...

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.)

0
1
Anonymous Coward

Re: nobody does that

http://en.wikipedia.org/wiki/Bcrypt

1
0
Anonymous Coward

Re: I wonder...

unless you choose a hash function that is fantastically hard to compute

Hence Whirlpool ;o)

0
0
Silver badge

Re: I wonder...

So 20 years should do it then...

0
0
Silver badge

Nice to know

This isn't very threatening, but it's nice to know where the technology is at these days. If it gets noticeably better, I'll add a digit to my passwords. In any case, if someone is able to get hold of the password database, then there might be a more pressing security hole.

0
0

Re: Nice to know

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...

0
0

Re: Nice to know

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.

1
0
Anonymous Coward

Re: Nice to know

No, no no. You've [i]completely[/i] missed the point!

What you should be doing is setting password expiry times to under 6 minutes!

;)

2
0
Facepalm

Splitting Passwords in Two

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.

3
0
Anonymous Coward

Re: Splitting Passwords in Two

And why did they make the same mistake nearly 20 years later with WPS?!

2
0
Silver badge

Not a good idea

I think (memories are hazy) it was done for backward compatibility with even earlier versions that had a maximum 7-character password.

2
2
Silver badge

Re: Not a good idea

Which were, in turn, probably handicapped by computational restraints present in the early 1990's.

0
1
Bronze badge

Re: Not a good idea

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.

0
0
Facepalm

Ironic but many Security “consultant” prefer NTLM + SSL over Kerberos + IPSec

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”

1
1
Silver badge

Re: Ironic but many Security “consultant” prefer NTLM + SSL over Kerberos + IPSec

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.

0
0
Anonymous Coward

Re: Ironic but many Security “consultant” prefer NTLM + SSL over Kerberos + IPSec

Or ROT13, applied twice?

3
0
Gold badge

Correct Horse Battery Staple

22
1
Bronze badge
Trollface

obligatory xkcd links

I'll trade you 538 for your 936

2
1

This is why I like 2-step auth.

Even if someone gets my hash and then manages to crack it, they'll still be locked out.

2
0
Joke

Re: This is why I like 2-step auth.

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.

1
3
Anonymous Coward

Re: This is why I like 2-step auth.

Sorry James:

Grievous joke alert abuse + misspelling sniggering = downvote

:P

1
3
FAIL

@AC 23:03

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

1
4

Re: @AC 23:03

Petty retort + American = Downvote

(not the original ac, and yes... This reply is equally if not more petty than the last.....

2
4
Anonymous Coward

Re: @AC 23:03

3) Eating a Marathon chocolate bar you fat American.

0
3
Pint

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.

4
12
Silver badge
Pint

Do I detect a hint of hyperbole and sarcasm?

1
0
Gold badge

@redniels

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.

1
0

Page:

This topic is closed for new posts.