User Empowerment: Password Security

World Password Day (who knew that was a thing?) is upon us. It is the first Thursday of May every year, and that falls on May 6th this year.

I’m not sure how to start this blog post, but the meat of what I want to get into is password security and the evolution over the years.

In the 1900s (… yes people are saying that now… feel old yet?), password security was pretty simple. The mainframe only accepted eight characters max for a password anyways, and it was case insensitive (many mainframes still operate this way). They also stored your password in plain text, where anyone with administrative rights (SysAdmin or criminal) could read them.

Different hashing algorithms started to become more widely used, like MD5, LM, NTLM, and SHA1. These hashes increased that maximum length ceiling and provided a fast and more secure method of storing the passwords. However, the speed of these hashing algorithms also meant that criminals could crack them quickly too. Researchers put in the time and found that by increasing the type of characters used (from just alphanumeric [a-z 0-9], to include special characters [a-z 0-9 ;!@#$%^&*()] ), they could make cracking these hashes exponentially more difficult. So, “Password Complexity” made it into every policy and standard. “You must require password complexity to be compliant” - PCI-DSS.

What went wrong is that computers and human psychology don’t always fit into the same mold. Asking human people to select a special character means not that they will select from the 100+ that are readily available on any given keyboard; no, they will choose the ones that are most common to their normal typing, such as exclamation marks, periods, question marks, and hashtags. The other bit of psychology that goes into here, and the reason why spaces aren’t on that list; is that many websites have their own list of “acceptable” special characters. This meant your personal list of “acceptable” special characters resulted from which ones caused the least amount of problems on the least amount of sites. For example, if you tried to use a space in your password on Facebook which worked, but then you tried it on your bank, and it didn’t work, the following account you tried to create probably wouldn’t have a space in it just because you didn’t want to go through the hassle of selecting a new password yet again.

Then along came password rotations. This was a bad idea from the get-go. Password rotations came about because people would select simple passwords that would be dictionary-based and fit into their world of acceptable characters that we talked about a second ago. This would result in passwords like Password1!. So, the idea went that if we force people to change their passwords regularly, this will make it so they have to pick a different password and which will reduce the window of opportunity for criminals to take advantage of weak passwords. This did not end well, and many companies are still in this phase. The result was passwords like Winter2020, then 90 days later, Summer2021. This is infinitely worse because instead of just a limited set of special characters being used, the majority of users would now be using a limited set of numbers (year) and words (season/month). These were actually guidelines detailed by NIST in NIST Special Publication 800-63B in 2017.

Then, in 2020, an update to NIST Special Publication 800-63B came in the form of more sensible standards that took human psychology into account. The update included focusing on length over complexity, spaces as special characters, regular password auditing, and a host of other things. But even in 2021, we as a security industry are having a tough time getting people to select “good” passwords.

So how do we do that?

By incentivizing security through user empowerment. We can do that through a tiered approach to password policies. This can work today in any organization with Active Directory but will probably take some heavy engineering to incorporate into platforms like Facebook and Twitter. I think we can get there.

Tiered password policies would work with both carrot and stick. For example:

• Tier 1: 8 character password minimum length
  • Benefits: easier password to remember
  • Downsides:
    • No VPN access
    • SSO session timeout set to 4 hours
    • Password rotation every 90
• Tier 2: 12 character password minimum length
  • Benefits:
    • VPN access - 8 hour session timeout
    • SSO session - 48 hour timeout
    • Password rotation every 6 months
• Tier 3: 15 character password minimum length
  • Benefits:
    • VPN access - 24 hour session timeout
    • SSO session - 1 week timeout
    • Password rotation every year
• Tier 4: 24 character password minimum length
  • Benefits:
    • VPN access - 48 hour session timeout
    • SSO session 2 week timeout
    • Password rotation only on change of status (exit, breach/incident, or team change)
  • Downsides:
    • ALL admin accounts, service accounts, and standard user accounts for admins would automatically fall in this category.

This is just an example. You can do this GPOs in active directory and simple integrations with your VPN profiles and SSO groups with most major vendors.

The only thing left is to give users the power to choose, either through trouble tickets or a custom form/site.

In 3 months, you’ll be surprised how many users have self-selected up to Tier 3 or 4. You also have a fantastic list (Tier 1) of people that need training or provided better solutions for selecting stronger passwords.

With all of that, this is my submission for #WorldPasswordDay.