Store Password In Reversible Encryption

What this setting changes in practice

Storing a password in reversible encryption means the directory can recover the cleartext equivalent, so the setting is fundamentally different from one-way password hashing. That difference matters because a compromise of the directory, the key material, or any path that can decrypt the value can turn a stored secret into an immediately usable credential.

This is usually a compatibility feature, not a modern security choice. It exists for legacy workflows that need the password itself for downstream authentication or protocol handshakes, which is why it should be treated as an exception state rather than a default account policy.

Why reversible storage is dangerous

The main danger is that reversible storage preserves the ability to reuse the password outside the directory. If an attacker gets directory access, key access, or a backup containing the encrypted secret and its decrypting context, the exposure is much closer to plaintext credential theft than to a hash crack.

That creates a larger blast radius than ordinary password compromise. The credential may be reused on other systems, unlock service flows, or enable access that was never intended to be recoverable from the directory layer alone.

Where organisations should look for exposure

Exposure assessment starts with the directory schema, account inventory, and any administrative groups or applications that require reversible storage. Organisations also need to check whether the setting was enabled broadly for convenience, because legacy defaults and inherited templates can leave many accounts affected without being obvious in normal access reviews.

It is also important to trace where the encrypted secret can travel, including replication, exports, backups, and any administrative tooling that can read directory attributes. If the system is internet-exposed or tightly integrated with other identity components, the setting becomes more sensitive because compromise paths are broader and detection opportunities are narrower.

Remediation, monitoring, and recovery

Where possible, the right fix is to remove the dependency on reversible storage and move the application or authentication flow to a design that does not require recoverable passwords. That often means replacing legacy protocols, changing service integration patterns, or isolating the affected account population until the dependency can be removed.

If the setting cannot be removed immediately, organisations should tighten administrative access, protect the underlying keys or secret store, and monitor for unusual directory reads, replication abuse, or export activity. After any suspected compromise, the password, related sessions, and any dependent credentials or service accounts should be reviewed and rotated as needed.

For broader guidance on encryption design and key custody, Encryption Guide and Encryption Buyer's Guide explain the control choices that determine whether encryption meaningfully protects sensitive material.

Risk and Threat Considerations

Reversible password storage creates a direct credential exposure risk because the directory no longer holds only a verifier, it holds secret material that can be turned back into a usable password. That makes compromise of the directory, backup sets, or decrypting key path far more damaging than a standard password hash exposure.

Failure mechanism: An attacker abuses directory access, backup access, or key access to recover passwords from encrypted attributes, then reuses those credentials for lateral access, persistence, or delegated authentication abuse.

Impact: The result can be account takeover, service disruption, broader identity compromise, and credential reuse across other systems that trust the same password.

Practitioner Guidance

Why practitioners should care: Treat this setting as an exception that needs ownership, not as a harmless compatibility toggle. If a business process still depends on it, the dependency should be documented, time-bounded, and reviewed like any other high-risk authentication exception.

Common misunderstanding: Teams sometimes assume that encryption alone is enough. In this case, recoverability is the problem, so the security question is not whether the value is encrypted, but whether the organisation can avoid storing a recoverable password at all.

Practitioner takeaway: The safest state is to remove the need for reversible storage, then verify that no residual accounts, templates, or legacy integrations still require it.

Related resources from NHI Mgmt Group

• Should security teams replace every password store at once?
• What do teams get wrong about end-to-end encryption in password managers?
• Who is accountable when a password manager is used to store privileged access credentials?
• How should security teams store high-value crypto seed phrases in a password manager?