Creating Better Passwords

Intro

The year is 2022 and the password war rages on. The heaviest casualties are IT support who constantly reset user credentials. The users are rebelling against the IT overlords that make their lives harder by asking them to create complex and long credentials. The users are under attack from hackers spamming multi-factor (MFA) authentication prompts to their personal devices. No one is getting any restful sleep, especially the CISOs… So, considering this, SEVN-X is happy to announce that we’re here to offer some holiday peace by posing an acceptable compromise for organizations out there struggling with end-user password policies.

Yes, password managers and MFA solutions exist but most organizations still have users logging into endpoints from memory because they are physically in front of a display. MFA internally is not really a widespread solution, neither is physical authentication hardware. Then there’s the problem of non-GUI network level authentication and protocols sending password hashes around that neither one of these solutions addresses. So, the burden is still on the user to create a strong password and remember it for logging into their device. This is where the problems begin—making users create long complex passwords, which then have to be rotated regularly. There are also third-party filters for blacklisting forbidden words/passwords or even blocking all dictionary words from being used completely. As an end-user, this can become a burden and result in more calls to the helpdesk for a password reset. Also, you can’t expect a user to create a completely random long password like a password manager, the user needs to remember it somehow, meaning it’ll be some sort of keyboard pattern if it doesn’t include real words.

Since the majority of password requirements are enforced via Active Directory (AD), let’s look at available options and since we know this may create unnecessary tensions in organizations, we’ll also talk through addressing issues so you can kick off your 2023 in peace:

Enforce Password History

This is a decent setting to have enabled to stop users from reusing old passwords. This honestly should not have any negative feedback from users and serve as good enforcement of actual password changes to something new. Now if the user only appends a new character to the end of the old password, this will work, but the password did in fact change to a different, although only slightly, password. Now the available values in this policy options range from 0 to 24, 0 meaning no old passwords are remembered, and 24 meaning that many are remembered in AD.

Maximum Password Age

This is where problems tend to begin in password wars. There are arguments for both regular rotations such as 30/60/90 days and longer periods such as 180 or 360 days. Speaking of the predictability factor from our password analysis, regular password rotations are a bad idea, period. It forces the users to create a new password every couple of months which basically turns into appending a new character to the old password, appending, changing the year in it, or setting it to the current month/year combination. We’ve seen way too many of these. That’s why most pen testers try common passwords with a year appended to them at the end because humans make predictable choices when specific constraints are put on them. The passwords are usually reset during identified user account compromises, so it makes sense to advocate for longer passwords (with some level of complexity) that are rotated let’s say once a year or every six months but not sooner. This is dependent on having a good password length requirement in place. The trade deal is that users make longer passwords but do not have to rotate them often enough where they get frustrated by the process.

Minimum Password Age

This setting exists to prevent users pretty much from re-using their old password by rotating password changes the number of times in the “Enforce password history” setting before going back to their old password. If you’re going with the suggested long passphrase policy and yearly rotation, this setting honestly should not matter as much and can be configured with 0. This is especially the case if the “Enforce password history” setting contains a double-digit number as its setting. If someone wants to really re-use their old password that’s like 20+ characters long, let them. Let the user have a small victory.

Minimum Password Length

This is also where users need to be gently nudged to pick good pass phrases (notice how it’s not a single word implied by password but a phrase which indicates plural). Using multiple words with some sprinkled digits and special characters can be quite a good formula, to protect users from password-guessing attempts and prevent pesky MFA spam because their credentials get compromised. Now because end users are human, they will choose probably dictionary words, which is fine, if they can remember the flow and it is long enough to reach desired length limit. To decrease a potential pushback, start by introducing good password creation guidelines in training to help users adapt better techniques for creating pass phrases while the length requirement is adjusted. Although a higher number of characters required may seem annoying at first even after training, once users have had some exposure and practice, the negative view will subside, leading to a stronger overall security posture for the organization.

Password Must Meet Complexity Requirements

This value should be set to enabled to ensure that a user tosses in a digit, a special character, and a mix of uppercase and lowercase letters into their credentials. It’s a good practice to make it a bit more difficult to guess the password or crack the hash of it, as long it’s not a predictable pattern like 2022/22/2022!/22! Type patterns are appended to the end…Again this is where guiding users to choose pass phrases that are longer and include uncommon insertion of special characters and digits comes into play.

Store Passwords Using Reversible Encryption

This is a big NO. The setting for this value should be disabled. Your NTDS database should not contain plaintext user credentials as this is a bad practice that does appear occasionally during our security assessments.
So, what does an example password end up looking like for a user with the proposed above policy?Knowing humans probably something like this:

• Ihatehav1ngLongpasswords@work [29 characters]

• Long26PasswordsReally!Suck [26 characters]

• WowMonday@herecanbe2022rough! [29 characters]

But again, the pass phrases above cannot be easily guessed and take extra effort when cracking hashes, so please go the route of long character requirements but don’t stress out people with constant rotations. We think everyone wins in this scenario, maybe except for us on our next pen test or that hacker password-spraying your Microsoft 365 instance. Remember to ease the end-users into high character number requirements by providing training or guides on making their credentials stronger for your organization.