Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

29 characters, including spaces...not bad. As long as the attacker doesn't know anything about your password and has to test all ASCII printable characters, that's over 180 bits of entropy in your password. So I think you're safe - the article says it would take 5 hours to hack an 8 character NTLM password. (which is not the same as LM (WinXP))

I think NTLM only keeps a 128bit hash, so if it were possible to brute force the entire key space, the attacker would likely find a hash collision that works as your password before finding your actual password.

My door lock is even more secure with a 4 digit pin. 3 failed attempts lock it out for several minutes. More failed attempts lock it for an hour. It doen't bother to tell you it is ignoring you during that period. A penalty instead of millions of free retries should stop that without physical access.

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.

I think it is time that we moved to two factor authentication as a whole.

What would be nice would be if there was one secure time/event based standard across the board for the authentication keyfob. OATH comes close, but there is always people/enterprises using SecurID. Perhaps something like the Google Authenticator, except with a stronger [1] hashing algorithm.

Ideally, it would be good to have multiple hardware devices, just like one keeps more than one key to a vehicle, and this can be a smartphone app, a dumbphone/featurephone app, a dedicated token like a Blizzard Authenticator, or a device that gets power when plugged into a USB slot.

One can add biometric authentication before the device offers the 6-8 digit code as well for three factor authentication (what you know, what you own, what you are.)

[1]: Perhaps multiple algorithms with the output XOR-ed together so if one algorithm is weak, it won't affect the unpredictability of the outputted numbers.

[2]: Reason one has it run from a computer is so it does not need to worry about having a battery. Even the best lithium ones eventually will fail in a couple years.

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.

Pretty much this. Brute forcing passwords over the Internet is silly and non-productive.

>it's likely they can do other stuff anyway

What, you mean like the Youporn chat registration list that had the usernames and passwords *and* verification email addresses in plaintext? Or like when Yahoo was compromised? Or like dozens of other companies were compromised? Or like when EMC was spear-phished out of RSA tokens?

>They that is account provider can easily use delays and lockout an account after too many tries.

Not lock out an account.

Temporary ban an IP address. Fail2ban does this. If you're just looking to protect SSH, use Denyhosts.

You don't want to lock out legitimate users. All the big providers like Yahoo and Facebook will let you keep trying at a password 3 times, and then they'll throw a captcha at you for all tries after that with as many tries as you want, because you have to keep solving the captcha for each attempt. Current captcha technology is pretty much bot proof - almost human proof sometimes, it seems (as a user, I hate captcha and knowing someone who is sight impaired, I consider it offensive - we should find something else, something better).

Locking out accounts over bad login attempts generates too many support calls and upset users, because you could DOS attack an account simply by spamming the login with bad passwords. It's been tried. It sucks as a solution. The solution is to make brute-forcing time consuming and requiring human intervention.

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.

Don't block accounts, ever...This causes inconvenience for the legitimate user of the account, and gives the attacker a trivial avenue for causing intentional disruption - if i know your username, i can lock your account out continuously causing you a major headache.

Also for any target of a significant size you don't try thousands of passwords against 1 username... You try 1 password (theregister published a list of the most common passwords a couple of days ago - start there) against thousands of usernames

In other words, why would a hacker who has already had an access to the server attempting to crack passwords over the Internet? Why not download (make transaction) the data and crack them locally?

The point is that, as long as you don't use the same password for multiple sites, cracking your password wouldn't allow the attacker to do anything they couldn't already do, since they've already broken into the system the password was supposed to protect.

What I do on my internet-facing server is simply to disallow password-based logins on ssh. Only public key can be used for authentication. Never had a problem with it, and it's just changing a few lines in/etc/ssh/sshd_config .

You are missing situations where for instance config files are stored separately. I have the situation where I are going on a customer site to replace defective network gear, and I get the config files to upload them into the gear before replacing them.
For security reasons, I don't get the configured console password, if I made an error, I would have to empty the config via recovery and start anew. I just replace the gear, phone the network guy of the customer and he then checks connectivity. It wouldn't help to modify the config before uploading to an empty password, because part of the configuration is the connection to an AAA server which kicks in as soon as the network connectivity is there, and then it closes all open consoles and locking me out.
But if I could brute force the shared keys whose hashes are in the config files, I might still get in.

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.

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.

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?

I've often thought about trying something like Password Safe, but I commonly use 4 different computers that I might need my passwords on. And 3 of those are at home where I might be accessing a bank. So unless there's some way around that problem I'm not thinking of, I'll stick to my main 6 or 8 long random ones.

Ha, what I really need is some sort of cloud password service. Wait...

I'd echo the other suggestion to use lastpass. I was struggling with the same issues. In theory the passwords are encrypted/decrypted locally and they do not have access to them. Of course, I'm sure they could be bruteforced as with any of the other sites. That said, I am a bit more inclined to trust one site whose sole purpose is storing passwords than every web forum on the internet. These days most of my passwords are randomly generated thanks to lastpass.

The real pain has been with smartphone apps, which don't integrate well with lastpass. I can access my passwords on the phone, but I have to do copy/paste to get the password into the app, and some apps are brain-dead and reset when context-switching which means I need to at least manually enter the username (which is a pita if it is a long email address).

People also point out keepass, but it doesn't support every OS I use. Lastpass always has the browser as a fallback if nothing else.

Thanks for the idea, and I hadn't heard of Lastpass, so I looked them up and found this [wikipedia.org]. Stuff like that, while probably never likely to affect me personally, still scares the hell out of me.

Yes, that's just one site. But if one site I use has their PW file stolen and broken I lose out on one site (and potentially any others I've used that specific PW for). If I trusted something like lastpass with my entire life and then they were successfully hacked...

That episode is the main reason why I've stuck with them - I was a customer at that time.

When that breach occurred nobody knew about it but them, but they immediately broke the news and generally treated the situation in the most conservative manner possible. Their treat assessments as communicated out seemed accurate to me.

So, sure, you're more secure if you never put your passwords out in the cloud to begin with - nobody can question that (assuming you still use strong unique passwords for each site and just carry them around with you on a PDA or USB drive or something). However, if you are going to use a cloud service then would you rather use one that has an episode like this and does full disclosure, or one that puts the marketers in charge and covers the whole thing up? The only reason you can cite that example is because Lastpass did the right thing.

If the alternative is to just pick a few memorable passwords and use them on many websites each, I'm not convinced you're better off.

And every password should use a different salt. Sure you can try 77 million combinations a second, but you can't check those results across the entire password file. You have to repeat the entire cracking process for each user.

That seems overly complicated - trying to accurately assign risk levels to different websites is beyond most people, and can potentially change out from under them if a website decides to increase its scope.

Here's what I do -- create a "base" password that is uber-secure, random line-noise sort of thing. Then I use a really simple algorithm where I take something from each website's name and prepend it to the base password (prepending is important since some websites silently truncate passwords).

I use a very similar setup, however one issue with the example you've given is that by using the first two letters of the domain means that even a bot could be written to compare the first N charaters of each password to the domain, and can make an assumption on what another domain's password could be. I know, it's a stretch.

A slightly better method is [for example] to prepend the first 2 vowels and append the last 2 consonants to the password. Sure, you have to remember slightly more complicated rules, and

i think email should be on the top list of priority - because "reset your password" on every other system tends to use your email address. lose control of your email and you've lost control of everything else.

An online email account often comprises the keys to the online kingdom. From looking at the email history you can often learn what usernames and accounts a person has on other services, and then reset all the login credentials for those other services. I'm pretty sure I remember reading about that exact sequence happening to someone high profile quite recently.

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.

This is not always true tbh. Stealing hashes can require as little as an unsanitized SQL query in a web application that allows an attacker to dump the hash table(s) using nothing more than a browser. It may or may not allow for user impersonation in order to do the stuff you listed, but the point is stealing hashes does not have to require complete hacking. In such a scenario strong passwords are still quite useful.

The most common way to acquire your password hash is via SQL injection, the web server is rarely compromised. Short of breaking the password storage, the hacker won't gain access to your password unless it's weak enough to generate.

A strong 12 char password has 612,709,757,329,767,363,772,416 possibilities, which even at quadrillion(10^15) guesses per second, it would take over 7,000 years to exhaust the entire space.

Assume the server has a database of hashed passwords, using one of the now vulnerable hashing algorithms. What the client is sending is for example a https encrypted password, not a hashed password? if you are the man in the middle, you are dealing with encryption not hashing? The https request is decrypted on the server, the plaintext client password is then hashed and compared to the hash in the database. I don't see how a man in the middle is related to hashes? (Then again I'm not a security guy in any s

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!

If you already have access to that system it's fairly trivial to install password capturing code.

The whole point is to engage in defence in depth - FreeBSD offers kern.securelevel to prevent you from being able to write to the file system, or change firewall rules. We have anti rootkit checking programs (do most people make regular use of rkhunter or anything similar?) Further, you need to encrypt and safely store backups. No password logging program is going to lift them from the hashes you got from the borrowed backup drives. Probably 60% of engagements I have been involved in managed to lift a backup drive from the environment, permitting only the tiniest changes to be made to live servers, thus minimising our risk of breaking things, and a (potential) black-hat's chance of being caught.

Making the hashes harder to crack makes it harder to crack into the server, live or from backups. You'd be surprised how many people forget backups.

Already have. Public/private key pairs, one of the modes of SSH. (And by far the preferred mode.)

Yes, we are rapidly approaching the point where the only way to secure a system is something you have, not something you know. Or at least, not solely something you know. That's all right. We're used to that. How do you start your car? Or open the door to your house? Something you have. And for any expensive car made in the past decade, that something you have isn't just the physical shape of the key.

Wohooo I am a ghost from the future who come flying in here at night to give you a peek at how the world could be if your idea gets realized, have a look at these future wikipedia articles, whohooooowooowow.

Agreed, but what we're likely to first see is every Bank and significant e-commerce site making you pay $5 for a dedicated keyfob, so that you now have to carry around a huge collection of them. It will turn out that half of them have other security problems, but that's OK since you're the one who had to pay for them.

What we really need is something like a strong two-factor openid system, or something like that. OpenID can already support this, but the problem is that few sites actually support OpenID. I

Right, then you have to login to some service from another computer....

If it's something that is really high security, Don't Do That Then (and you certainly shouldn't be doing it using a password).

For normal "domestic" security, carry a USB dongle containing your private key and enough processing power to encrypt challenges. For 'belt and braces' add a PIN, password or fingerprint reader needed to unlock the device. For belt, braces and really thick underpants have a second PIN or password checked by the service you are connecting to.

It's only weak passwords when you have access to the hash database what's broken. You can always throw in more characters to make brute-forcing take exponentially longer. And since some hashes have been proven to be NP-hard, there's nothing you can do better than brute-force them. No useful hash can be harder than NP, but I'd say that's good enough for me.

Also, in a majority of cases, if you can obtain password hashes, you may just take whatever was protected by that hash. Not always:for an encrypted fi

No it means that if someone can steal the password hashes then your passwords are known....

Why is the database of passwords on a machine that is capable of being stolen in the first place, this is like the soldier having a list of challenges and responses written down where anyone he challenges could potentially see the entire list...

The solution is for the user facing machine not to contain the hashes just an API to check individual passwords as needed

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.

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 article only talks about very old deprecated algorithms which to be quite honest if you are reliant on those for your security you have far more trouble then just weak passwords or someone brute forcing. NTLMv2 has been in available for use in windows since the NT 4 days and LM/NTLM were off by default from vista onwards.

You are describing LanMan (LM) hashing, not NTLM. And it is even worse than being limited to two runs of 7 characters, they are upcased before hashing so mixing case has no impact. NTLM still sucks (and there are rainbow tables due to the lack of salting), but it is a major improvement over LM.

Just as a note: using a rainbow table will crack the password very quickly, but that is because you (or someone else) expended a lot of computing time to generate those tables. And those tables take up space. Not much

Let N be the number of bits of real entropy in an item of human memory. N is somewhere between 50 and 70. (Proof: you can remember RWOLZEKBYT or "correct horse battery staple" [xkcd.com] if you have to, but you've got no prayer of remembering RWOLZEKBYTDUQLZPEJNB or Rw3L$E5Kÿ(t. )

Let 2^R be the instruction rate of the largest computer affordable by a large nation or corporation. R is about 56 at the moment.

2^(N - R) is the number of seconds before we're all completely fucked.

You can pull those truly out of thin air and since they are rehashed 4000 times brute forcing those is slow even on most modern hardware. Generally in the range of a 1000 to 5000 keys per second.More than a thousand years for a 8 character password. And you can't even use a shorter password on WPA.

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.

algo_name, hash(salt + password)...that way, if your algorithm of choice proves to be a bit feeble, you can gradually upgrade to a better one by getting your users to change their passwords. If anyone's account has a really old algo still on it, then the account gets disabled. Whilst this doesn't "solve" the problem, it means you don't have to throw everything away because someone found a quick way to compute hashes using your chosen algorithm.

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

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 tim

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.

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

Having been, up until just a few months ago, one of those unwise people who used the same, only moderately complex password everywhere, for everything, I understand the convenience issue. There are dozens of sites that want you to login, and you can't remember dozens of passwords. Best practice is to maintain separate passwords, so the loss of one won't affect the others... but that doesn't feel like something that could happen to YOU. Then, something DID happen to me; I got a warning from the Guild Wars

I'm not the GP but there are a few measures that can be considered such as

1: deliberately slow hash functions. You can make the crackers job a few orders of magnitude harder this way.2: dedicated password checking servers (ideally a seperate machine but privilage seperation on the same box is better than nothing) so that cracking your webapp doesn't hand the attackers the password hashes on a silver platter.3: physical hardware the user is given that provides one-time use security codes

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.

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 reverse1) check the hash against your "end of chain" hashes2) If the hash has no match you do the same "mapping" that you did while creating the rainbow table into the password space3) 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 chains4) 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 hash5) 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

Generally speaking, you don't make a gazillion tries through the actual authentication gates; that sort of brute force is an obvious threat that people know how to look for, like an army of barbarians storming the gates of the city. The kind of action described here is more an army of monkeys on typewriters trying to guess passwords off a stolen list of passwords; eventually, they'll get it. They won't know they've gotten it unless they already had (the hash of) your password to begin with, but that's doa

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.

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.

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.

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.

You can actually lock that down in the profile manager (yes, there is a "no-login" profile). You can take away the abilty for users to access programs and run executables, which means the OS is "practically" locked-down.

The only downside? The same "no-login" profile is required for accessing Safe Mode, so if you have an unrecoverable problem be prepared to reinstall:D