This presentation was initially delivered as part of the One Identity Unite User and Partner Conference in September of 2024 in San Diego, California. Topic today is "Passwords are still required, so let's make them perfect." My name is AJ Lindner. I'm a solutions architect with One Identity, and I specialize in our Active Directory Management and Security Solutions.
Passwords have been problematic and unfortunate standard for a very long time. While newer, more secure passwordless solutions are an enticing alternative, there's a lot of factors that make it difficult to implement. This, of course, starts with technical debt, especially from legacy or bespoke applications that don't support the secure modern authentication protocols that are required in order to implement.
There's also often high costs and a large implementation effort when trying to deploy this to all of your applications and all of your infrastructure. And passwords, in most cases, are still used either in certain scenarios or as a backup option.
So let's face it. Most of us still need passwords for now. So let's do everything we can to make them as secure as possible while still accounting for memorability and usability.
So who determines what makes a password secure? Well, the National Institute of Standards and Technology does in Special Publication 800-63B Revision 3. This is their digital identity guidelines for authentication and life cycle management. And Revision 3 was released as far back as June 2017. I'm going to be referring to Section 5, the Authenticator and Verifier Requirements, which contains the guidelines for memorized secrets, which includes passwords.
Now, these guidelines have remained pretty much unchanged for more than seven years now. And yet, so many organizations are still depending on older, more outdated paradigms about what makes a secure password. As a reference, Verizon's 2023 data breach investigations report showed that over 49% of breaches involved credentials.
Also, earlier in 2024, the SpecOps Breached Password Report revealed some pretty interesting information. In their investigation, they concluded that 88% of organizations still use passwords as their primary authentication method. And out of that 88%, only 50% of them are scanning for compromised passwords more than once per month.
Over 31 million of the breached passwords were over 16 characters long. 40,000 admin portals were still using the default admin as a password. And a lot of the most common passwords that they found were variations of the word "password" or keyboard walks like "qwerty" or other silly things.
What's interesting to note, too, is from the research performed as part of this report by Kraken Lab, they suggested that the minimum length for an Active Directory password should be 13. But we'll see some additional notes on this in just a moment.
So what are these old, outdated, insecure password paradigms? Well, it's the things that we're all familiar with, starting with composition rules, also known as complexity requirements, where a password requires you to utilize some combination of a capital letter, a lowercase letter, a number, and/or a symbol. And, in many cases, certain symbols are restricted. You have to pick from this arbitrary list of symbols that are allowed.
It also includes arbitrary frequent password rotations, like every 30, 60, or 90 days, I have to go change my password no matter what. In addition, arbitrary maximum lengths, like in the example we see here, where your password can't be longer than 20 characters for some reason. And it very often includes a weak minimum length. For example, did you know that the default Active Directory password policy has a minimum length of only seven characters?
So what's changed? Well, in Revision 3 of this NIST requirements, they specify that the minimum length of your password should be at least 8 characters. If you have to have a maximum length, that should be at least 64 characters. All printing ASCII characters, unicode characters, and the space character should be allowed inside your password.
You should no longer require composition rules or complexity requirements. You should no longer require arbitrary periodic password changes, but should only force a password change in the event of a compromise. And perhaps most importantly, we should be comparing passwords to avoid values that are commonly used, expected, or known to be compromised.
So this includes things like passwords obtained from previous breach corpuses or compromised credential databases, common dictionary words, the use of repetitive or sequential characters, like all A's or 1, 2, 3, 4, and then context-specific words. So using Active Directory as an example, again, that might include things like the user's SAM account name, their email address, their UPN, et cetera.
Now, we're in a bit of a weird in-between time when it comes to these NIST standards. This presentation was initially prepared back in March of 2024 and presented in September of 2024. But since then, I have uncovered Revision 4 of this NIST standard.
Now, Revision 4 is not yet official. It's currently in a public draft where it is open for anybody to go read, and it is open to the public to submit comments and suggestions. Now everything that I just discussed is still relevant here, but there is a very distinct change that's been made to most of these requirements in the new Revision 4. This comes down to NIST's way of clarifying things in "should" versus "shall" phrasing.
In Revision 3, most of these requirements use the phrase "should," meaning that these are a recommendation from NIST versus the word "shall," which means it is a strict requirement in order to adhere to the standard. So certain requirements have now moved from a recommendation to a requirement. And, in particular, minimum length must be at least 8 characters. That is a hard requirement. Whereas, it should be at least 15 characters. That is their recommendation.
You shall not have composition rules, and you shall not require periodic or arbitrary password changes. And you absolutely shall require a comparison against a block list that includes breach corpuses, dictionary words, and context-specific words.
Also, a note-- NIST has ditched the phrasing of memorized secrets that they used in previous revisions and has now just gone with the term passwords. Although, they clarify this includes other things like passphrases and pins as well.
Ars Technica has a great article going through most of these changes in Revision 4. And here's just a quick reference to the ones that have changed in "shall" versus "should" phrasing. So how do we, or rather, how does NIST, justify these changes from the old password paradigm to the new?
Now, a lot of us have probably seen this well-known XKCD comic before, which kind of captures the exact justification. Historically, we've been creating passwords that are not necessarily more difficult for an attacker to guess but are absolutely more difficult for a user to remember.
And this also pushes the idea of switching to a passphrase, which is some combination of multiple random words that are a lot easier for a human to remember, but due, in particular, to their length are much more difficult for an attacker to guess.
And that's exactly what NIST says. As humans, we have a limited ability to memorize complex, arbitrary secrets. So we choose passwords that are really easy to guess. Now, when NIST originally introduced composition rules, it was to increase password complexity. And these requirements were based on the entropy calculations that they performed at the time.
But through further calculation, and especially through analyses of breached passwords, they determined that the benefit of this is not nearly as significant as they initially thought, but that the impacts on usability and memorability is severe. So their original entropy calculations were shown to be not particularly accurate, and their new approach is based primarily on the length of the password.
So length is the primary factor in password strength. Something too short is susceptible to brute force attacks, password spray attacks, and dictionary attacks. We should be encouraging our users to make passwords or, in particular, passphrases as long as they want to. And we should be able to have max limits, but they need to be reasonable. Hence, that 64-character recommendation.
If we're talking online attacks against passwords, these can be severely mitigated by rate limiting. If we're talking, again, in Active Directory, for example, did you know the default Active Directory policy does not include a lockout? So there should be a lockout policy in Active Directory to prevent online attacks.
Offline attacks are more of a concern because if I've got that list of hashes, I can do whatever it is that I want to them for as long as I want to. So I can compute billions of hashes per second. I've got no rate limiting, nothing stopping me from trying to guess those passwords. So we want to make them as secure as we can against different types of attacks.
Now, a lot of people are still kind of hanging on to the concept of composition rules. But let me show an example on why those don't necessarily make a better password. My password is password. I need a capital letter. Capital P password. I need a number-- Capital P password 1. I need a symbol-- capital P password 1 exclamation mark.
That is not a significantly more secure password by any stretch of the imagination. It's also in every single dictionary list that an attacker's using to try and guess passwords with. It's going to be there. It's going to be one of the most common that people are going to try and use.
If you've ever tried to enter a password that requires symbols but had your symbols get rejected because they have a specific list of symbols and you can only select from that list, you know that these kinds of things really just lead to more user frustration. And people don't want to have to set their password meeting these weird arbitrary requirements.
Also, complex passwords are just less likely to be remembered overall. And this is what leads to people putting sticky notes on the server rack with the admin passwords. Or they've got a Word doc on their desktop with all their different passwords to all the different services they need to access.
Just overall, we use predictable passwords, and hackers love it. This is why password sprays are such an effective and common attack because we're using the same dumb passwords that we continue to use over and over again.
So it's really extra, extra important that we are comparing against our deny list, that we are ensuring passwords being set are not already known to be compromised, are not immediately guessable, just a single dictionary word, or are not otherwise easy to determine if I've got other information about the account.
So some additional suggestions and considerations to keep in mind. Starting with this chart and others like this, these are very commonly shown to justify the reason for composition rules in passwords. But I'm going to point out a few flaws, at least in how password attacks are more commonly done today.
The first thing this is, of course, referring to a brute force attack, where it's a lot more common these days to not really do a brute force attack, but to do a dictionary attack or to do a password spray. Or I'm taking some list, whether it's incredibly short, in the case of a password spray, or incredibly long, in the case of a dictionary attack, and I'm just going to try all million passwords in the top one million most common passwords list that I grabbed off of GitHub or off of the darknet somewhere.
So I'm not very often, as an attacker, going to be just trying everything from 0 to all Zs. But also, these are assuming that the key space you're using as an attacker is limited to whatever that column is.
So yeah, if I'm only using numbers, and you have 13 numbers as your password, and that's the only thing I'm using in my attempts to crack that password, yeah, I might be able to get that right away. But most commonly, I'm not going to be doing that. I'm going to be doing some sort of variation, some sort of combination of different characters. And most of those password cracking tools today can do this automatically for you. So it's not quite as relevant as it seems. But either way, length is still going to be the biggest factor in determining what makes a password more difficult to crack, but also, especially more difficult to guess.
Now for some additional suggestions. Originally, this was me suggesting a minimum length of 13 based on the Kraken Lab research versus NIST's recommendation of 8. But now that we have the public draft of Revision 4 available, I'm instead suggesting we go with what will most likely become the new standard and go with the recommended minimum length of 15. And, of course, along with this, encouraging passphrases and training your users on what a passphrase is and trying to get them to switch over to that instead of a traditional password.
We should, of course, be checking against as many user attributes as you want, to be fair. If we're talking AD, this should include things like the UPN and the email address, as well as maybe first and last name or certain identifying information like the department or job title.
Regardless of the scenario, we should always have MFA on top of this. In particular, strong forms of MFA. Now, this same special publication goes really in depth on what constitutes strong MFA at different levels of assurance. There will be a short slide at the end here that kind of summarizes what NIST defines there.
But what seems to be the standard today in most organizations is mobile push authentication that also requires biometrics or a pin. And if you want to be extra secure and very clearly pave the path towards a passwordless future, I'd suggest going with a cryptographic hardware MFA device, something like a smart card or a YubiKey or Windows Hello for business.
And this will allow you to maybe start kind of a hybrid rollout of password lists, where certain things are only requiring your YubiKey and your pin or your fingerprint in order to get in, but you still have the password available for some of those other systems or applications that are going to require a password no matter what.
And finally, we want to check against these breach corpuses as often as possible. Of course, every time a new password is set, that should be run up against that breach corpus and rejected if there's a match. But this also needs to be audited frequently.
If I set an incredibly secure password today, and of course, we no longer have arbitrary password rotation policies, that could get breached two weeks from now. And we need to know about that as soon as we can so that we can then force rotation of any credentials that match that breached password.
So now that we know what defines a secure password, how do we actually implement that inside of our environment? Well, we can do that with One Identity Password Manager.
For those who aren't aware, Password Manager is a self-service password reset solution for Active Directory that can also synchronize passwords to other systems as well. And this starts in Password Manager with a password policy. And these policies can be defined well above and beyond what you can do with Native Active Directory tools.
So this starts by defining a length rule that has a minimum and a maximum. Despite what the screenshot shows, we would put a minimum of 15 and a maximum of 64 or higher. We can also define our sequence rule here, which disallows passwords that have multiple characters repeated over and over or in sequential order.
Additionally, our policy can also enforce a user properties rule that prevents common properties that exist on that user's AD account from being included inside their password. So like we said before, things like UPN, email address, first name, last name, et cetera. And we can also enable a dictionary rule that prevents passwords from matching anything in our custom dictionary list.
And in the general settings, you can enable the compromised credential checker. Now, by default, this uses VeriCloud's CredVerify service, which is an enterprise service for checking compromised credentials against their database of options. That is fully researched by their own independent team and kept up to date accordingly. If you want a free and open source alternative, you can go to the One Identity GitHub and download a solution that utilizes haveibeenpwned instead.
Now, at this point, we have a web portal available for your end users to perform their own password resets following the policies and rules that you've defined that align to the NIST standards. But let's take that a step further and apply it in other ways as well.
One Identity Password Manager comes with some optional components that you can choose whether you want to deploy or not, and one of those is the Password Policy Manager, or the PPM. What this does is it installs the password policies that we configured just a moment ago as a password filter on your domain controllers.
So now instead of only enforcing those password policies when passwords are reset through the Password Manager Web Interface, these policies can also be enforced whenever a password is reset against the domain, no matter where that comes from.
When deploying the Password Policy Manager, it's common practice to also disable any domain password policies that might apply so that the two policies don't conflict with each other when a password is reset in or outside of Password Manager.
Another option you might choose to deploy is the Secure Password Extension, or the SPE. This allows your end users to perform self-service password resets using the Password Manager self-service web interface from the Windows lock screen the same way they might do today via a Control-Alt-Delete password reset. This is designed to be deployed via group policy using an included administrative template containing the configuration options necessary to roll this out to all of your end user workstations.
When deploying the secure password extension, it's common practice to disable the option to reset your password or change your password through the Control-Alt-Delete option available by default in Windows workstations. And this is what that secure password extension looks like to an end user.
They simply navigate to a separate credential provider on their Windows lock screen that is entirely configurable by you as an admin that launches a secured web browser and takes them to the same Password Manager self-service portal that they would navigate to otherwise if they were on site logged into their machine on the internal network.
So we've covered everything about what makes a password secure and how to implement that in One Identity. Password Manager. So let's finish up with some final thoughts and a couple references for further investigation.
Now, there's a few caveats that I want to point out. The first one is that the desktop self-service password reset solution that activates from the Windows log-on screen now will always require an active internet connection. Whereas, before it might have been available to reset the local password offline.
Now, you can still configure offline password reset where offline means not on the corporate network. As long as you have a public-facing self-service website, that is an option available inside of Password Manager, where it will reset both the domain password and the locally cached password on that workstation.
Another caveat is that the Password Policy Manager component, which enforces those password policies directly on the domain controller, regardless of where those passwords are being reset through, does not perform that live compromise credential check against that external compromised credential service.
So this is another reason why it's imperative to schedule some sort of process that regularly performs that check. We should be performing them on every password reset as well as on a schedule to ensure that passwords that might be secure today, but are no longer secure a week from now, are reset as they need to be.
In addition, the only accounts that should be able to perform password changes in Active Directory are those domain admins that can do so anyway. Anybody else who needs delegated permissions in order to perform a reset on like a standard user account should be doing so through the Password Manager Help Desk site, through delegated permissions assigned through Password Manager.
Anything outside of that scope, if we're talking things like privileged accounts or service accounts, that should be managed from a privileged access management solution, like One Identity Safeguard, to protect that privileged access, or otherwise, set and rotate passwords for those service accounts where users don't need to actually memorize those on a day-to-day basis.
And the final caveat here is regarding certain other regulatory boards. What we're talking about today is recommendations that have been around for a while from NIST, but not hard requirements. Although, those hard requirements might be coming.
Certain other regulatory boards are still stuck in the previous old school password paradigms that were created years ago by NIST and have yet to update their requirements to align with the recommendations that NIST has been proposing for the past seven years. Hopefully, with this new upcoming revision, if they stick to the same things that we're seeing currently in the draft, those regulatory boards will adjust their password requirements to align with what NIST suggests is the new common gold standard.
To close this out, I'll leave a few references up here. We've got both the Revision 3 version of 800-63B, which is currently the standard today, as well as the publicly available draft of Revision 4 that is open as of the moment of making this presentation to public comment and public feedback.
We also have a link to the SpecOps 2024 Breach Password Report that I referenced earlier, as well as the Password Manager compromise credential checker replacement that utilizes the free and open source haveibeenpwned that is available on the One Identity GitHub, and the Ars Technica summary report of the Revision 4 of that same NIST document.
Now, I'd be remiss to not follow up this presentation on password security without mentioning multi-factor authentication. Now, this same NIST document also specifies standards for multi-factor authentication. And they do this via what they call authenticator assurance levels.
These basically define how sure you, as an organization or as an authenticator, can be that the person performing that authentication controls those authentication factors. Not that they are who they say they are, but that they control those factors.
And you can also see per this chart how everything besides authenticator assurance level 3, for the most part, recommends a memorized secret on top of some other multi-factor authenticator solution, and why I recommend utilizing a multi-factor cryptographic hardware device so that you can achieve authenticator assurance level 3 without also requiring a password, but you can still use that where it's needed in your environment.
If you have any questions about this presentation or anything else delivered at One Identity Unite 2024, please feel free to reach out to One Identity. And I'd like to finish off by thanking all of our wonderful sponsors who supported One Identity Unite 2024 in San Diego.