How Reversible Passwords Compromise Active Directory Security

Misconfigurations are the bane of cybersecurity—especially in Active Directory (AD), where a simple group policy mistake can leave the entire network exposed to attackers.

Given the prevalence of credential theft, password policy seems like an aspect of security that organizations would have mastered by now. However, a survey of users of the Purple Knight AD security assessment tool revealed a surprising finding: more than 20% of organizations with between 501 and 2,000 employees had the “Store passwords using reversible encryption” security policy setting enabled. For enterprises with 5,001 employees or more, 16% had it enabled. 

Why do so many organizations have this risky setting enabled? After all, very few applications designed today require this setting. In fact, there are a few valid reasons for enabling this setting. But the security risk it poses is significant, and organizations need to weigh the value of having this setting enabled. 

Reversible Passwords Open the Door to Cyberattacks

Let’s start by examining how encryption works in AD and the difference between an encrypted password and a hash. Both encryption and hashing are ways of scrambling data. However, while encryption is a two-way function, which allows encrypted data to be decrypted, hashing is not—meaning the original data cannot be retrieved. 

In AD, passwords are stored as hashes by default. In Windows environments, passwords are hashed using the LAN Manager hash (LM hash) and the Windows NT LAN Manager hash (NTLM hash). Of the two, the LM hash is considered weaker and is limited to 14 characters or fewer. The LM hash is used to enable backward compatibility with Windows 95, Windows 98, and Windows ME.

When a user logs in, the password they enter is hashed, and that hash is checked against the password hash stored in the directory. The fact that hashes cannot be reverted to their original form makes them more secure than encryption and better suited for authentication.

However, the extra security provided by hashing is rendered moot when the “Store password using reversible encryption” setting is enabled. Allowing passwords to be decrypted or reversed makes life easier for a threat actor, removing the need for them to use password cracking tools such as John the Ripper. An attacker who has obtained access to a domain controller and launched a successful DCSync attack, for example, can pilfer user passwords in plain-text form.  

Twenty years ago, enabling this setting might have made sense, as some applications used protocols that required knowledge of the user’s password for authentication. Today, this policy is rarely justified. Some legacy applications in your environment might require the setting to be enabled: If updating these apps to remove this requirement continually gets set aside in favor of other priorities, the security risk climbs. The risk also increases with apps that were created by third-party developers and are no longer supported. For example, if the Challenge Handshake Authentication Protocol (CHAP) is being used through remote access or Internet Authentication Services (IAS), reversible passwords must be allowed. Digest Authentication in Internet Information Services (IIS) requires it as well. 

Microsoft warns about the risks of reversible encryptionOpens a new window in strong terms, stating that “this policy should never be enabled unless application requirements outweigh the need to protect password information.”

See More: The Future of Encrypted Data in the Cloud: 3 Things to Understand

Reversible Passwords are Risky

A substantial part of securing Active Directory involves reducing the attack surface—minimizing risk by remediating misconfigurations, patching vulnerabilities, and implementing constant monitoring. At the GPO level, lax attention to security or an unwillingness to re-examine the necessity of security policies can open doors that make Active Directory easier to compromise.

On this subject, Microsoft has shown organizations the way. Reversible encryption is automatically disabled in the Default Domain Group Policy Object and in the local security policy of workstations and servers. Remember that disabling the policy does not remove the encrypted passwords from Active Directory. Each encrypted password is removed only when the user changes their password after you’ve disabled the policy. If the reversible encryption setting must be enabled, organizations need to ensure that it is enabled only on certain accounts and not globally. 

As Microsoft notes, the justification for having this policy needs to be strong enough to outweigh the security concerns. If the applications that require this functionality are not critical, the risk exceeds the reward.

Did you find this article helpful? Tell us what you think on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d be thrilled to hear from you.