Password strength – fiction, fact, or what should secure your environment?

[BrianKunick]

The trouble with passwords…

Trouble... We’re not talking about the yellow sticky-notes on the side of monitors or employees sharing passwords. Password composition is at issue. Passwords used today are generally the same as what we were using 20 years ago. This might be acceptable if all other variables within Information Technology have remained the same since then. They haven’t. Those who have not adapted may have placed their IT assets at considerable risk.

Will my password effectively secure everything? 

Twenty years ago, probably.  Remember the old IBM auto-password generators that gave us hard to remember passwords with the mix of alpha/numeric and special characters that were 8 characters long? That is because that is the number of spaces the operating systems and applications would recognize for passwords. The mix of characters from the password generators might give us something like this: n&}P2^XJ …pretty easy to remember, right? It must be secure because it looks so complex! Not true either. Today’s password cracking arrays make quick work of this password. A couple of minutes to be exact. And, this is where it really goes fast! In 2012, ARS Technica reported that a 25-GPU cluster could crack every possible combination of 8-character passwords in under 6 hours. Again, that was using 2012 technology. What about today?

Still feeling secure with your enterprise password policy?

Justifiably so, you are possibly starting to break a sweat while digesting this habanero of a topic.

Today, we understand much more about strong passwords than we did in the past. NIST has modified their guidelines for password deployment, which we’ll discuss further shortly. What defines a strong password? Is it upper-case, lower-case, numbers, special characters? This is what we’ve been taught. The answer in the past has been yes to all of the above. 

To understand what delivers a strong password, we must know what drives password cracking. The two predominant forces are tables/dictionaries of common passwords, and brute force. Tables and dictionaries provide long lists of commonly used or suspected passwords. The crackers can check your password against entries in the tables at light-speed. Brute force involves guessing each character in your password, and takes a little more time due to the number of variables (upper/lower case, numeric, special characters) to run through. But, remember, all possible 8-character combinations are cracked in less than 6 hours…

What is a strong password? 

Entropy and Search Space come into play. What is Entropy? Well, think of our complex, hard to remember, but easy to crack password from earlier: "n&}P2^XJ".  Entropy relies on excessive complexity to be “unpredictable,” in theory. But, we saw that our example password could be cracked in a couple of minutes. Is Entropy still delivering strong passwords? 

Search Space factors in the length of the password in terms of total characters and the number of possible variables included in the password (upper/lower case, numeric, special characters) to determine what the total number of possible passwords can be derived from that combination. In simple terms, the “length” of the password in terms of characters is most important, with some complexity added.

Let’s look at the statistics in this table:

PASSWORD	PASSWORD CHARACTERS	SEARCH SPACE = POSSIBLE PASSWORD COMBINATIONS	EASY TO REMEMBER	EASY TO CRACK	TIME TO CRACK
n&}P2^XJ	8	6,704,780,954,517,120	NO	YES	1.12 minutes
Thisisagreatpassword!	21	33,337,810,962,573,359,664,680,352,920,577,639,625,185	YES	NO	1.06 hundred thousand trillion centuries

While “Thisisagreatpassword!” takes a large amount of theoretical time for advanced cracking systems to solve it, does that make it a strong password? Yes and no. Statistics is a funny thing. Have you heard of anyone winning the lottery on their first try? It does happen. Likewise, depending upon how password crackers have their search or brute force mechanisms structured, they too could hit your password on the first try. The point is to make it as difficult as possible for the password crackers to ever crack your password. 

Back to NIST…

NIST has revised their password guidelines as they do periodically. Currently, they still suggest 8-characters with complexity as the bare minimum for a password. Should that be your enterprise password policy? Probably not, unless the variables affecting your Information Technology environment are the same as 20 years ago, or you can afford to lose control of your data or afford regulatory fines for those losses. The rest of us want a more secure password policy. This is also where NIST steps in. As a maximum, NISTS’s revised guidelines recommend 64 characters for your policy with some complexity. Why? Because they realize the value of a long password in protecting your IT assets from credential exposure via password cracking.

Are Password credentials enough to protect your assets?

No. Passwords are not enough to provide secure authentication. Once again, things are not as they were 20 years ago. Our practices shouldn’t be either. 

Multifactor Authentication should be used to enhance strong passwords. Multifactor is something you are: biometrics, something you know: password/PIN, something you have: FOB or card (magnetic strip or RFID).

Sure, MFA equates to more cost, administration, user training, etc.. But, can you afford to lose control over your data (PHI, PII, Financial, etc) Where are things going in the next 20 years? Quantum computing for example? Now how long will it take to crack a strong password?   

Use MFA, with a strong password/passphrase of at least 14 characters with some complexity. Defense in-depth, layer your security.

Credit to:  ARSTechnica.com, NYPost.com, NIST.gov

Brian R. Kunick, is a CIO/CSO servicing the operational and security requirements of the enterprise.

[SemperFi_guy]

Great read,  I agree that passwords are simply not enough to protect your systems.  I work heavily in the UNIX/Linux space and am currently discussing why a password vaulting technology is a BAD idea to secure our UNIX/Linux systems.  The idea of just using native password controls to secure my critical systems is alarming to me, not to mention having to give the password vaulting technology full blown root access to all of my servers to manage the passwords... WHAT.  

[BrianKunick]

That is great insight you offer with regard to password vaulting.  Most solutions or those designed internally don't take into consideration all of the factors that are necessary at a bare minimum to store passwords securely. 

These variables are just some of those needed, and of those in this list, they need to be modified to take into account ever-changing variables in the environment we work in:

• Use a strong random number generator to create a salt of 32 bits or longer.
• Feed the salt and the password into the PBKDF2 algorithm.
• Use HMAC-SHA-256 as the core hash inside PBKDF2.
• Perform 40,000 iterations or more (August 2017).
• Take 32 bytes (256 bits) of output from PBKDF2 as the final password hash.
• Store the iteration count, the salt and the final hash in your password database.
• Increase your iteration count regularly to keep up with faster cracking tools.

[SemperFi_guy]

Agreed!.

Call me old school but I still like agent based technology to secure my environment.  I want to protect not only the front door but also the windows, vents, etc...  Using a vault solution is easy and for some environments I am sure it is the right choice (windows system accounts, db account, etc) but easy does not always mean secure.

[sdurbin]

@SemperFi_guy

Password vaulting isn't the only option for Linux-based systems.

PAM allows easy integration with multiple authentication mechanisms. The benefit there is that they remain logically separate.

For example, local/AD passwords could be combined with a second auth mechanism. e.g. a software, or hardware token, via RADIUS.

There are a great deal of options available.

The question of suitable password complexity should no longer be our focus.

The more pertinent question is whether a sufficiently complex password is enough on it's own.

The answer is... no.

[SemperFi_guy]

I agree,  I was simply voicing my opinion on using passwords in general(which turned into my dislike for password vaults as a PAM solution).

I today leverage a technology that actually removes the requirement for a password in most cases for the accounts within my UNIX/Linux servers.  Only those accounts that require a password are provided with one and all others are assigned a non-hash able password.

[BrianKunick]

Very good point.  Entropy, or password complexity no longer offers the protection of the past.  I agree with you as also mentioned in my article that passwords alone are not enough to provide secure credentials.  Passwords of sufficient strength are not meant to stand on the own anymore.  MFA must be used. 

[sdurbin]

SSH key management is also an area where, in organisations of all shapes and sizes, I have seen some very questionable security practices in the past.

However, more recently there have also been improvements in that domain too!

[arctific]

For password strength to mean anything, the strength has to have a definition.  The only good in a password is how long it takes to crack after capture.  For my purposes, password strength is the time it takes to have a 50/50 odds of cracking a password after capture of a password hash.  If the password is captured by a key logger, read from a post it or a vulnerability allows a clear text version of it to be captured from protected memory -- the password is directly captured rather than cracked.  Such problems are not addressed by password strength.

Two useful bits of math.  

1. First password crackers grow faster than Moore's Law over time, closer to 11 times faster every 10 years for the same dollar cost in crackng hardware.  This happens as the hardware gets faster, the price of the faster hardware goes down with time and speed optimiztions in chips, storage, bandwidth, and software improve performance.  
2. Passwords chosen by humans are not as difficult to search 50% of the available choices as password generated at random.  My samples of cracked password files from multiple clients cleanly show a pareto like effect -- 20% of the combinations to search are responsible for 80% of the passwords found.  Approximately then, if a human chose the password about 10% of the commbinations to search are worth 50% of the passwords captured to crack. If randomly chosen then 50% of the combinations to search are worth 50% of the passwords captured to crack.

Now it is time to describe the search space.  Humans like words, even if they add leet adjustments.  But each language on earth has word frequency by length of words.  For single place passwords there is a very short list. As words go, there are only two such words, "A" and "I".  A peak in the middle near 7 place words happen that is used by "CorrectHorseBatteryStaple" to generate a password and then there are very few words longer than 29 letters.  "Supercalifragilisticexpialideaxious" is alone at 31 letters long. Really, "CorrectHorseBatteryStapple" is a four place password with 3 7 place words and 1 5 place word.  A variable with every word 7 places long can be listed out and all its leet combinations and the entropy of this password is actually smaller than XKDC thinks it is.  Still it is not all that bad.  Once we know the places of a password to search and the number of options per variable the math of combinations is not that bad.  I use spreadsheet functions to help.  Lets stick with Letters, Numbers, Symbols and Extended Ascii for example

N_l = places of letters 

N_n = places of numbers 

N_s = places of symbols

N_e = places of extended ASCII

It starts with placement of these variable inside the password then goes to places and finally combinations.

Combo = Placement * Places

Placement = fact(N_l + N_n + N_s + N_e) / (fact(N_l) * fact(N_n) * fact(N_s) * fact(N_e)

Places = (52)^N_l * (10)^N_n * (31)^N_s * 163^N_e

If human selected then true combinations to search is closer to 10% * Combo.

If a random password generator selected then the true combos to search is near 50% * Combo.  

Both will lead to the 50/50 odds of cracking the password.

Now for the effect of Moore's law on password cracking speed.  For simplicy we will use 10 times faster every 10 years for the same true dollar spend on the cracking rig.  The math still works even if the attacker simply buys a new rig each year and splits the combinations to search among them over time.

Combinations per second = cps

cps(t) = cps(0) * 10^(T/10years)  

C(t) = cps(0)*(sec/yr)*10years*ln(10)*(10^(T/10yrs)-1)

T(C) = 10 years * ln(C/(cps(0)*(sec/yr)*10yrs*ln(10)+1)/ln(10)

T(C) = 10 years * ln(Combs / (cps(0) / (365.2425*24*3600*10*ln(10)) +1)/ln(10)

From this, we can actually compute password strength once we know how fast a password cracking rig is and what it cost at least once in history and project forward correclty accounting for Moore's Law such as the drops in price of computing hardware over time, inflation, speed improvements in software, upgrades in hardware over time.

The Macbook Pro Air -- 32 GB flash ram -- I wrote this from now costs about 2.3k and in August 2013 achevied 6 billion combinations per second.  If I bought the next cracking computer for 3.3k, with the right specificaitons  it would be faster.  Note: splitting the job among parallel computers often gets eclypsed by the growth in speed of Moore's law so parallel computing is only really useful over a 5 year horizon or so, unless it is just cost effective per compute cycle.  Consider that sometimes Amazon Cloud Services does not charge full price if you do not download data but only use compute cycles.  

So what is a strong password really?  First consider the 6 billion combinations per second problem.

1. Average language has 100,000 words.  10 leet combos per word, 1,000,000 combinations to test.  6,000 languages later, we have a single word password with leet cracking in a target time of 1 second.  
2. The password is forced to change ever 3 months.  Such a password better have a half-life -- time to reach 50/50 odds of cracking -- longer than 3 months.
3. The average password cracking effort lasts about 2 hours.  All the easy cracks fall out quickly and watching the computer grind gets boring after a while.  Even Police units admit to self terminating password cracking efforts after about 36 hours.  So, the password at least needs a half-life of 36 hours or so.

Care to use the math above to work out how long your password would last against my Macbook that costs 2.3K?

Simply sort your language or spell check dictionaries by word length assemble variables by word length.  GNU Aspell is not a bad source for free dictionaries in many languages.

Go long and memorable.  Avoid short words.  Skip leet and just add complexity to meets the allowed limits.  Even one place longer than a pre-computed Rainbow Table and the password has a chance.

[EnviableOne]

@arctificthis is why the latest advice is use a random password generator and secure encrypted vault for any passwords. this then obviscates any rainbow tables, and improves the complexity.

Beyond this, it comes down to using behaviour and environmental scores turning to a risk based approach. If they are logging in from their desk at the time they usually come in, after having swiped in the building, then a password may be sufficient, if they are loging in form an unrecognised device in a country you dont operate in over a wifi network then maybe step up to a second factor