//Hurry! Everyone add “1” or “!” to the end of your 8-character passwords now!

Seeing all the “your 8-character passwords are dead!” posts and articles gave me a good laugh as that’s already been the case.  We have been down to reasonable offline cracking times even with modest hardware investments for a while now.  There are also several caveats to saying that an 8-character password is dead, but I’ll get to that later in the post.  For those wondering, most all of these posts were spurred by a recent announcement by hashcat that a tuned version of 6.0 had achieved 100GH/s NTLM speeds using a single Nvidia GeForce RTX 2080Ti (https://twitter.com/hashcat/status/1095807014079512579).  Some news sources keep saying “8 cards” but that’s not the case as they show only a single card in the 100GH/s benchmark.  Besides, my meager 6 x GTX 1060 cracking rig at home already achieves 120GH/s for NTLM and given the advancements in GPU technology I’m not surprised by the benchmark speeds of the RTX 2080Ti.

But let’s take a step back for a second and detail how that 8-character NTLM password hash was already crackable prior to this new hashcat benchmark and GPU release from Nvidia.  Our goal in the following example is to see how long it takes to offline brute-force an 8-character NTLM hash.  We’ll assume you have a set of different budgets just to give a sense of the spend required to achieve certain cracking times:

• Scenario 1 – We have old hardware laying around that we purchased long ago – I’m using this as an example to show how rapidly the cracking times have dropped – so let’s say this is a single GTX 960 card capable of 10GH/s speeds on NTLM hashes (circa 2015).
• Scenario 2 – You have a budget of ~$3,500 with which you could easily buy a smaller GPU cracking rig that has 6 GTX 1060 cards on which to run hashcat and you’d get to 120GH/s speeds on NTLM hashes.
• Scenario 3 – You have a budget that is double, or ~$7,000, which would get you 8 GTX 1080 cards and speeds of 350GH/s on NTLM hashes. 
• Scenario 4 – You don’t want to buy hardware, so find that the p3.16xlarge EC2 instance on Amazon AWS fits your needs as it has 8 Nvidia Tesla V100 GPUs available for $25/hr. and is able to reach 633GH/s NTLM speeds.
• Scenario 5 – You have a budget of ~$12,000 in which nets you 8 RTX 2080Ti cards and speeds of 800GH/s for NTLM hashes.

Next, we need to look at total keyspace of our password.  Ignoring that many people choose repeatable or known patterns when selecting and updating or changing their passwords (see: http://www.malos-ojos.com/?p=771), and assuming that we need to brute-force the entire keyspace (we’re really unlucky and only match on the last and final combination), we can calculate maximum cracking time for any 8-character password based on the time it takes (at our guessing rate) to exhaust the keyspace.  Assuming there are 95 possible characters (upper alpha, lower alpha, numeric, special characters, etc. – the “ascii-32-95” set) and a password length of 8, we have:

• A keyspace of 95^8, or 6,634,204,312,890,625 possible combinations. 

Those who started in security when we used CPUs to crack would recognize that keyspace as an almost insurmountable task and we’d be discussing how many “2 to the power of something” years it would take to crack.  Also, while I gave up on rainbow table years ago, writing this made me question if anyone has even bothered to generate NTLM 8-character “ascii-32-95” tables (the 8 char NTLM mixed-alpha + numeric tables are ~127GB) as I have never seen them, publicly traded at least.

 But I digress, so let’s see how our scenarios above play out and determine maximum cracking time:

• Scenario 1 – 663420 seconds = 11057 minutes = 184 hours = 7 days 16 hours
• Scenario 2 – 55,285 seconds = 921 minutes = 15 hours 24 minutes
• Scenario 3 – 18,954 seconds = 315 minutes = 5 hours 15 minutes
• Scenario 4 – 10,480 seconds = 174 minutes = 2 hours 54 minutes
• Scenario 5 – 8,292 seconds = 138 minutes = 2 hours 18 minutes

From these results we see that even with a limited budget of ~$3,500 that we need less than a day to crack a hash (remember, that is a maximum length) that previously, using CPUs, would take years.  If we assume on average that we need to exhaust 50% of the keyspace before a match then these times drop by half, meaning we should be cracking hashes in ~7.5 hours on that same $3,500 system.

What I find interesting about Scenario 4 is that although you have no upfront hardware costs you quickly exhaust your funds if you have a large number of hashes to crack.  As an example, if you cracked 160 NTLM hashes, again assuming worst case scenario where we need to exhaust our keyspace, we would have hit the $12,000 mark in fees and could have simply purchased our own hardware for the job.  Speaking of costs – one interesting thing to note is the cost per GH/s of cracking speed as it goes down the higher your budget.  At $3,500 you’re paying $30 per GH/s and at $12,000 you’re paying half, at $15 per GH/s.  Seems counterintuitive, but the more you spend the less it costs per unit of GH/s.

Finally, as I was reading the articles, news reports, and tweets about this topic I noticed a few mis-conceptions or discussion points that have popped up that I’d like to address here:

• Why all the buzz around password lengths of 8 characters and where did that recommendation come from? 

It comes from a variety of sources, one of which is NIST guidance.  And while there are sites and services that allow you to use less than 8 (see this: https://www.troyhunt.com/how-long-is-long-enough-minimum-password-lengths-by-the-worlds-top-sites/), most corporate environments will default to the recommended minimum length of 8 in their password policies.  However, that guidance may have been (read: is) based on dated information, thinking back to CPU-based cracking and much slower rates, which meant that an offline attack against an NTLM hash would not be successful and because we have maximum password ages and rotation requirements it isn’t an issue…but it is, and has been for some time.  Even PCI requirement 8.2.3 states a requirement for a minimum 7-character password length, which significantly reduces the keyspace we have to cover in brute-force attacks.

• But my company requires me to rotate my password every 30/60/90/X days, so we should be good, right?

Not really, if the numbers above hold and I can break your NTLM hash in under 3 hours, unless I’m very unlucky and the time between obtaining the hashes and cracking them offline plus the 3 hours of cracking times coincides with the same day you either manually rotate your password (unlikely) or are forced to by the system (more likely) then I have access for at least 1 to as many days in your maximum password age policy.  If my goal is to log in as you and download your mailbox as an offline .pst then I’ll probably be successful.

• What about password complexity – doesn’t that help?

Not really, but sort of.  In my scenarios and brute-forcing time calculations above I accounted for all 95 characters, which would include your special character requirement.  Not to mention, you likely have a password that conforms to a well-known standard (see: http://www.malos-ojos.com/?p=771), which means I can use rules and wordlists to more effectively crack the hash and could more effectively attack your hash.  In fact, if you kept the 8-character length requirement but ditched the complexity requirement (assume mixed-alpha numeric only) I could crack your password (in the best case above) in 4.5 minutes as opposed to 2 hours and 15 minutes).  So yes, I say sort of as it increases the keyspace and increases brute-force time – but also not really considering your special characters either start or end your password which is a pronounceable root word or words.

• Why the focus on NTLM hashes?  Does the hash type matter?

Hash type absolutely matters – ask an old security professional about LM hashing and they will regale you with stories of the olden days and rainbow tables and domain admin access every time.  If you look at NTLM, which is an MD4 hash of the plaintext password, it is a very fast algorithm.  Meaning it is fast to calculate and makes it more susceptible to brute-forcing as you’re allowing me to test more (higher rates) plaintext inputs to match the MD4 hash output.  I also focus on NTLM (-m 1000 for the hashcat crowd) as that is the default storage mechanism in Microsoft Active Directory.

That being said, NTLM isn’t the only hash type out there…and no, we don’t need MD4 to be as fast as it is for password storage or authentication.  Which brings us to other ways in which we can store based on passphrase-based key derivation functions such as PBKDF2 (https://en.wikipedia.org/wiki/PBKDF2) which isn’t very GPU resistant but obviously better that MD4, and algorithms such as bcrypt, scrypt, and now Argon2 (https://en.wikipedia.org/wiki/Argon2).  As an example of the slow down in brute-forcing, a single GTX 1060 can do 19 billion MD4 calculations per section versus only 240,000 per second for scrypt.

• Does this mean you can use these GPU cracking rigs against websites?

No, and that’s the difference between online and offline attacks.  What I’m covering here are offline attacks, meaning the attacker has the hash in their possession and can attempt to recover the password/crack the hash on their own system.  This usually occurs if the organization has been breached, someone has gained admin access to a system or the domain, and has “dumped” the password hashes (or captured them in transit across the network).  Online attacks would require a different toolset and would operate at much slower speeds/rates.

But this brings me to a different point, as we gain cracking rate speed it also means those password hashes dumped on the internet become even more susceptible to cracking, depending as stated above on the hashing algorithm used.  Then again, we already know the general format of the password and that many web services allow 6-7 character non-complex passwords, and while many have obviously fallen because of this I’m speaking of the more complex passwords that have not, until now.

• Anything you haven’t covered?

A lot, and I mean A LOT!  We haven’t even touched FPGA and ASICS here, precomputation, side channel attacks, and a whole lot of other stuff related to password storage, hashing, and cracking…and I stuck with unsalted password hash storage versus network authentication algorithms for simplicity.