How Revertible Passwords Compromise Active Directory Security
Misconfigurations are the bane of cybersecurity, especially in Active Directory (AD), where a single Group Policy error can expose the entire network to attackers.
Given the prevalence of credential theft, password policy seems like an aspect of security that organizations would have already mastered. However, a survey of users of the Purple Knight AD security assessment tool revealed a surprising result: over 20% of organizations with between 501 and 2,000 employees had enabled the “Store passwords using reversible encryption”. For companies with 5,001 or more employees, 16% had it activated.
Why have so many organizations enabled this risky setting? After all, very few applications designed today require this setting. In fact, there are a few valid reasons to enable this setting. But the security risk it poses is significant, and organizations should weigh the value of enabling this setting.
Reversible passwords open the door to cyberattacks
Let’s start by looking at how encryption works in AD and the difference between an encrypted password and a hash. Encryption and hashing are ways to scramble data. However, while encryption is a two-way function, which allows encrypted data to be decrypted, hashing is not, which means that the original data cannot be recovered.
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 less. The LM hash is used to provide backward compatibility with Windows 95, Windows 98, and Windows ME.
When a user logs in, the password they enter is hashed, and this hash is checked against the hash of the password 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 additional security provided by hashing is rendered moot when the “Store password using reversible encryption” setting is enabled. Allowing passwords to be cracked or reversed makes life easier for a malicious actor, eliminating the need for them to use password cracking tools such as John the Ripper. An attacker who has gained access to a domain controller and launched a successful DCSync attack, for example, can steal 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 may require the setting to be enabled: if updating these applications to remove this requirement is continually pushed aside in favor of other priorities, the security risk increases. The risk also increases with apps created by third-party developers that are no longer supported. For example, if Challenge Handshake Authentication Protocol (CHAP) is used through remote access or Internet Authentication Services (IAS), roll-up passwords should be allowed. Digest authentication in Internet Information Services (IIS) also requires it.
Microsoft warns of the risks of reversible encryption in strong terms, stating that “this policy should never be enabled unless the requirements of the application outweigh the need to protect password information”.
Learn more: The future of encrypted data in the cloud: 3 things to understand
Reversible passwords are risky
An important part of securing Active Directory is reducing the attack surface, minimizing risk by correcting misconfigurations, patching vulnerabilities, and implementing constant monitoring. At the GPO level, a lax attention to security or an unwillingness to reconsider the need for security policies can open doors that make Active Directory easier to compromise.
In this regard, Microsoft has shown organizations the way. Reversible encryption is automatically disabled in the default domain GPO and local security policy for workstations and servers. Remember that disabling the policy does not remove encrypted passwords from Active Directory. Each encrypted password is deleted only when the user changes their password after you have disabled the policy. If the reversible encryption setting needs to be enabled, organizations should ensure that it is enabled only on certain accounts and not globally.
As Microsoft notes, the rationale for this policy must be strong enough to outweigh the security concerns. If the applications that require this functionality are non-critical, the risk outweighs the reward.