Cracking 14 Character Complex Passwords in 5 Seconds
ciozone.com
ciozone.com
http://en.wikipedia.org/wiki/LM_hash
"To address the security weaknesses inherent in LM encryption, Microsoft introduced the NTLM algorithm with Windows NT 3.1."
That's 17 years old news, that LM is weak.
Still what most people unfamiliar with the topic don't know is that LM hashes of your passwords can still be present on your Windows machine, default "for compatibility reason."
Basically Ophcrack uses optimised hash chains to speed things up. The precomputed hashes are generated with a specific character set. This works particularly well for unsalted algorithms that support limited character sets such as LM. LM splits the password into two on the 7 character boundary, capitalises it and only supports a subset of printable characters. Also it's unsalted, so while more computationally expensive than NTLM it's actually easier to crack. Rainbow tables for LM can be downloaded from freerainbowtables.net and are about 30-40Gb.
NTLM on the other hand supports unicode and very long password lengths. Most rainbow tables are mixalpha, or alphanumeric but short length. Our mixalphanum with symbols rainbow table set goes up to 14 characters and is about just under a terabyte. This is more difficult to put on SSDs cheaply.
Your best bet to protecting from rainbow tables is to use a character not referenced in commonly available sets in your password as you inevitably otherwise reach the limits of security vs usability with exceptionally long characters. As I use british keyboards, I generally recommend the £ symbol (British pound) or accent over a vowel. The Euro symbol is also good if you're staying in Europe.
Your best bet to protecting from rainbow tables [..]
For anything else, ready salted is definitely the best crypto flavour.
Having said that, a few years ago I co-ordinated a distributed effort to create rainbow tables for standard Oracle database accounts. Oracle's crypto mechanism uses the username as a salt. It meant that we had to generate different (but small as the algorithm was crap) tables for DBSNMP,SYSTEM etc. The same applies to WPA-PSK - don't use a common SSID in the Church of Wifi tables.
I guess the moral of the story is that salting alone won't get you out of the woods. You need to think very carefully when it comes to crypto, and get as many second opinions as you can.
The solution to that threat, the real threat, is scrypt, bcrypt, or PBKDF2 --- the "adaptive" hashes that can be tuned to trade a marginal increase in defender cost for an untenable increase in attacker cost.
For as long as there's people using unsalted MD5 hashes in their PHP applications, Rainbow Tables are a real threat.
> incremental crackers [were used to] harvest thousands of passwords [and] forced Unix systems in the 1990's to adopt "shadowed" password files.
As someone who is interested in security but has not spent significant time studying it, I'd be interested to hear more about this. How did Unix solve the rainbow table issue? What is an incremental cracker and how does it relate to shadowed password files? (I'm familiar with the latter but not the former, and a Google search generates more noise than signal without more keywords to go on.)
Incremental password crackers, like John the Ripper and Crack, take a single password hash, and an actual dictionary, and hash each entry in the dictionary looking for a match. They take days to run instead of seconds, and until people started wanting to break into Windows boxes, they were the only way people cracked passwords.
Incremental crackers have improved substantially over the past few years primarily due to the introduction of GPU programming (in some cases algorithms port easily, in other cases they need some work first to be optimal on a GPU), easier distributed programming and rainbow tables. There's some interesting projects that use GPU technology to optimise the rainbow table reduction function (see http://www.cryptohaze.com/ for an example). As GPU technology improves and as hardware becomes cheaper and more powerful these technologies bring capabilities previously limited to three-lettered agencies into the commercial and home space.
It's disabled by default on Vista and 7 (AFAIK, it was on my Windows 7 build, and I don't think that was me) but is enabled by default on Windows XP. You can find out how to disable it here: http://support.microsoft.com/kb/299656
If an attacker has both the salt and the hash, they are back to computing the table (brute force)
I am not familiar with windows password scheme but it would be crazy if windows just relied on the hash. Few *nix machines that I deal with have 128 bit salt + password.
Even wifi-wpa, blackberry and iphones are doing password strengthening to make brute force method more challenging.
As most of us are familiar with, most vulnerable part of the security is us human beings picking the passwords. Underneath algorithms(hashing) are pretty well devised and solid when used properly.
My personal method is to work with two salts; one static half (just for the added entropy) kept with the login code, and one dynamic half (always random - not computed from user input) kept in a separate database, away from the hashes. This forces the attacker to acquire not just the database with the hashes, but also the database with the salts, AND the application's login code, in order to get anywhere.
If you really cared about the security of your passwords, you'd use scrypt, bcrypt, or PBKDF2, all of which are markedly more secure than "salted" anything.
Hmm... not quite. The word "salt" is always used in the context of KDFs. I'm not entirely certain how I'd define the difference between a salt and a nonce, but they feel like subtly different concepts to me.
If you really cared about the security of your passwords, you'd use scrypt, bcrypt, or PBKDF2, all of which are markedly more secure than "salted" anything.
Well, to be fair, scrypt, bcrypt, and PBKDF2 all use salts too. :-)
KDFs are a bit of a back-alley in crypto research, and that's the only place the term exists. The argument devolves to whether nonces really are a concept distinct from salts. I'd attempt to win the argument by citing nonces used in ways similar to salts in other crypto protocol settings (there are many).
If you look at PBKDF2, the only reason they call it a "salt" is because they're referring back to the original Unix work, where the term originated.
One way to slice this particular apple is to say that "salt" is a conventional systems design term, and nonce is a cryptosystems term.
This business of calling out "salt" vs. "nonce" as a crypto shibboleth though --- am I just being pedantic? No. Read generalist programmers writing about their idiosyncratic "salt" schemes --- "1/8th of the salt is stored on non-writeable media! 1/4th of it is encrypted with an AES key! 1/2 is stored in the database but XOR's against my mother's maiden name!" --- regardless of the three (3) papers you can cite by real security people using the term, in reality, people talking about "salts" are almost invariably distorting and tangling themselves up in silliness when they really ought to be taking PBKDF2 off the shelf and getting on with their lives.
The term 'salt' also appears in the definition of the PSS signing scheme. And in the HAIFA hash framework. And in some disk encryption schemes.
in reality, people talking about "salts" are almost invariably distorting and tangling themselves up in silliness when they really ought to be taking PBKDF2 off the shelf and getting on with their lives.
Sure. But I maintain that 'salt' is a good word whose reputation has been ruined by the idiots who use it, rather than being inherently a bad word. :-)
Have to concede Biham's HAIFA paper to you.
Fair enough. But let's face it, people RFC 3447, not the original paper.
You saved me some typing there! Anyways I concur.
So, 300 billion passwords per second is still a very impressive load, but the keyspace for WinXP passwords is somewhat limited, which would also explain why 80 GB of rainbow tables are sufficient.
But correct me if I'm wrong.
From Vista onwards, I think, LM is no longer used.
It would be interesting to see if the effort that is spent writing programs to load stuff from disk and avoiding seeks gets redirected to solve other problems.
It's like a thief got into my house and is now able to open the front door. So what?
There's no cracking going on here, just short-cutted brute-force attacks.
Let's say we want to have a rainbow table for all passwords 14 characters long.
Let's say we only work with upper and lowercase English characters (26+26) and digits (10), so 62 possible characters.
To just store all the possible passwords would take 14 * 62^14 bytes = 1.617 × 10^17 gigabytes.
You need to process all the passwords (once) but only 1/N of them (for some large N) are stored on the disk.
Always.
There are 2 examples there which should give you a clear idea what your parent post was referring to.
As computers get faster in every aspect the ability to crack naively implemented hashes grows greatly, to the point where, as we've seen, 14 character random passwords protected by a one way hash can be cracked in very little time.
Using a static salt across all accounts saves you a little, because it means that in order to crack those hashed passwords it will be necessary to re-do all the pre-computed hashes. That takes a lot of time and resources, but once done every vulnerable password (which today means any password less than 14 characters, no matter how secure) can be cracked.
By using a good per-account salt it then requires a brute force attack for every account. Which makes any requirements you've instated on minimum password "strength" all the more effective.
If, however, you use too short of a salt, or a silly "salt" such as phone number or userid or first name or some such then your salt becomes much less worthwhile. As pre-computed rainbow tables grow, as hardware gets faster eventually you get to the point where you can crack passwords along with naive salts quite readily. Phone number + 8 character password is just 18 characters, it's really only a matter of time before rainbow tables are capable of cracking 18 characters directly, and then using phone numbers as a "salt" is meaningless, because attackers can crack the password+salt directly.
What's better is to use a very long and random salt for each and every password (random length doesn't help that much). In this way any pre-computed hashes are worthless, because it's extraordinarily unlikely that any significant subset of all of the possible salt + password combinations have been covered.
The article you point to is about LM hashes, not NTLM hashes. There is no way to stop using NTLM hashes on Windows.
This URL shows you how to force NTLMv2: http://windows-secure.net/O.Reilly-Securing.Windows.Serv/059...
The idea is to try to force Kerberos authentication only. I can't find any tips on forcing it explicitly (even through group policies) but perhaps there's a firewall method to disable any [NT]LM auth and only allow Kerberos auth. I think some specific services may only allow NTLM (such as Telnet) and some services (such as IIS) may have to explicitly be configured to use Kerberos.
(edit) I should mention that I am not an expert on configuring Windows domains or their authentication (obviously) but according to some random guy I asked in IRC, if the SPN is set on a calling ID for a given service, Kerberos will always be used (or attempted anyway) and enabling TCP instead of UDP for the communication may help it get through firewalls etc (and solve some other login-related problems with UDP attempts). However, I think NTLM is the only one that can get through all manner of proxies, firewalls, etc (for IIS for example).