Active Directory Passwords – Who is Right?

This was originally posted as an INSIGHT for Wolf & Company, P.C. here.

Background

Cybersecurity breaches are making the news on what seems like a weekly basis. Many of these incidents involve unauthorized access to systems and data as a result of compromised user credentials. These credentials are compromised through improper storage, weak password criteria, and the re-use of previously compromised passwords. In a recent Krebs on Security article, the average price for stolen credentials on one forum was $8.19. When looking at credentials tied to e-commerce and online banking, the average price jumped up to $15. The financial motivation to steal credentials, along with the trend of moving more systems to a web-based Software-as-a-Service (SaaS) model, puts a heavy burden on system administrators to ensure credentials are securely stored and generated using strong criteria to resist any off-line brute force attacks.

There are many different guidelines, frameworks, and “best-practices” available for you to choose from, which is truly a double-edged sword. These guidelines are developed with the intent that they are implemented fully, which means you as the administrator need to have an in-depth understanding of each of the requirements. Our goal here is to distill the major requirements and issues of the following guidelines:

• Microsoft Active Directory Best-Practices
• Multi-factor Authentication (MFA) with Active Directory
• NIST SP 800-63B Digital Identity Guidelines

We will break down these authentication guidelines, as it applies to a Microsoft Active Directory (AD) environment. Although this is not the only network operating system, this is by far the most widely used. Additionally, many organizations have implemented Single Sign-On (SSO), which increases the value of a compromised AD account.

Microsoft Active Directory Best Practices

Although this guidance was developed for the Active Directory environment, these requirements can be evaluated for use in most systems. Microsoft recommends enforcing the following requirements:

• Password History: Twenty-four passwords remembered. This protects against end users re-using recent passwords.
• Maximum Password Age: Sixty days. This limits the amount of time an attacker has for brute forcing.
• Minimum Password Age: One day. This prevents the user from rapidly changing their password to get around the Password History restriction.
• Minimum Password Length: Fourteen characters. This length intends to extend the time required to brute force the password.
• Complexity Requirements: Password contain characters from three of the five character sets (a-z, A-Z, 0-9, ~!@#$%^&*_-+=`|(){}[]:;”‘<>,.?/, and Unicode characters).
• Store using Reversible Encryption: Disabled. This stores the password in a more secure (hashed) state.

While this seems like a robust authentication standard, we have found this is not the perfect solution. On many internal penetration tests, we are able to obtain users’ AD credentials passed over the wire as an NTLM hash. Pass-the-Hash techniques are not always feasible, so we often use a dedicated password cracking server to brute force the NTLM hash and recover the plaintext password. Although our machine is optimized for this specific task, the performance is not out of reach for an attacker. Using high performance graphics cards, we are able to brute force 178,200,000,000 passwords per second. 

The potential passphrases following the Microsoft guidelines are much greater – ninety-six standard characters and a fourteen character minimum password results in 5,646,733,123,551,136,024,526,585,856 possible passwords (96¹⁴) – but end users make the cracking much easier. A true brute force of all possible passwords would take roughly 1,004,807,703 years at the speeds shown above. Tools like HashCat make the cracking time significantly shorter by using intelligent rules. As an example, below are several passphrases that meet or exceed the Microsoft recommendations. This screenshot was taken after seventy-two hours of cracking.

These passphrases meet each of the requirements noted above, yet many of them follow similar patterns. First, these are all comprised of dictionary words, with the addition of a few numerical or special characters, which are usually appended to the end. Many also contain mostly lowercase letters, with only the first letter capitalized. This demonstrates why training in effective password composition is essential, regardless of the quantitative rules that you enforce.

To be fair, an attacker has to have access to your network or a mobile machine, such as a laptop, to compromise these password hashes. If you are still uncomfortable with these types of mitigating controls, tools like Fine-Grained Password Policies and the Cred Defense Toolkit can enforce stricter composition requirements, and can even “blacklist” some of the easy to guess passphrases.

Multi-Factor Authentication (MFA)

We have several clients that have implemented MFA for authentication to their internal network. They saw the offline attack capabilities, and wanted to develop a solution that was both easy for the end user, and secure against offline attacks. Microsoft includes a listing of the supported MFA providers:

Provider	Offering	Learn More
Gemalto	Gemalto Identity & Security Services	http://www.gemalto.com/identity
inWebo Technologies	inWebo Enterprise Authentication service	inWebo Enterprise Authentication
Microsoft Corp.	Microsoft Azure MFA	Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications (see step 3)
RSA, The Security Division of EMC	RSA SecurID Authentication Agent for Microsoft Active Directory Federation Services	RSA SecurID Authentication Agent for Microsoft Active Directory Federation Services
SafeNet, Inc.	SafeNet Authentication Service (SAS) Agent for AD FS	SafeNet Authentication Service: AD FS Agent Configuration Guide
Swisscom	Mobile ID Authentication Service and Signature Services	Mobile ID Authentication Service
Symantec	Symantec Validation and ID Protection Service (VIP)	Symantec Validation and ID Protection Service (VIP)

Additionally, Microsoft has developed Hello for Business which is a Microsoft implementation of MFA for Active Directory environments hosted in Azure. These MFA options allow administrators to loosen the requirements on end users for a single factor (password), while still securing the authentication process. Even if a password is compromised, the attacker will be unable to access resources without the second factor.

NIST SP 800-63B Digital Identity Guidelines

Many people refer to the NIST publication, which did not increase the minimum length recommendation as many other standards have, when talking about their password requirements. When this special publication was announced, it seemed to be all that the media and headlines would mention. While it is true that NIST is recommending a minimum password length of eight characters, it is important to understand all of the mitigating controls NIST is recommending that reduce the risk of credential compromise. To help break down this special publication (SP), here is the exact NIST language with a translation.

Definitions

NIST Language: The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.

Translation: SHALL means this is a required control, and no exceptions are allowed. SHOULD means this is a best practice control. The organization is strongly encouraged to implement this control, but it is not required.

Blacklisting Credentials

NIST Language: When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

Translation: The organization is required to compare user-created passwords against a “blacklist” of passwords and passphrases that are “commonly-used, expected, or compromised.” The bullet points included above are suggested ways of meeting this requirement, but are not required. Additionally, the organization is required to alert the end user why the attempted passphrase was rejected. This will be resource intensive, either in person hours of identifying leaks and performing the checks, or investing in software to perform this test. Tools like Fine-Grained Password Policies and the Cred Defense Toolkit can help enforce stricter composition requirements, and can even “blacklist” some of the easy to guess passphrases.

Complexity and Expiration

NIST Language: Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Translation: Organizations are strongly recommended to not enforce any complexity requirements. Additionally, they are also strongly recommended to not enforce a maximum password age with forced rotation. These two best practices go directly against the Microsoft recommendations noted above. The thought process here is that people over-simplify passphrases just so they can hit the complexity requirements (e.g. “Christmas 2017!” above). Additionally, people will rotate a number to keep 99% of the same password (e.g. “Ilovemyfamily5” above). Organizations need to heavily invest in end-user training, because they are required to monitor for compromised credentials. If compromise is detected, either through the blacklist noted above or other means, a password rotation is required.

Password Hints

NIST Language: Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g. “What was the name of your first pet?”) when choosing memorized secrets.

Translation: This is less of a concern when looking at AD, but several organizations now offer self-service password resets, which typically rely on Knowledge Based Authentication (KBA). Password hints and other knowledge-based “secrets” are not allowed. These answers are almost always comprised of public data, and are typically re-used in every location that offers KBA.

Password Storage

NIST Language: Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs, then generate a password hash. Their purpose is to make each password a guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack. The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185]. The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output.

Translation: In the case of network access, Active Directory is the Verifier. The NTLM hashing mechanism used by Windows Active Directory, does not have the capability to meet this requirement; NTLM hashes do not have a salt or a cost factor (both are functions to make even weak hashes exponentially more difficult to crack offline).

Action Items

This was written to give you the quick facts for each of these guidelines. In most cases, you will be able to adopt and implement any guidance you wish. When choosing a framework, make sure you fully understand what you are committing to. If there are requirements in the guidance that you will not or cannot implement, you need to ensure this decision is documented, and that you have determined that the gap does not significantly undermine the security of your user authentication process.

This summary is also just that, a summary. Your specific environment will have unique challenges, and you may have to spend time assessing which systems will rely on the authentication method chosen. For example, do you have any SSO technologies that are only compatible with legacy password guidance? Do you have the capital to invest in additional technologies – either to provide a second factor to end users, or to monitor for breached credentials and search your credential storage these breached credentials?