Password & Secret Redaction

This document covers how IdentityMesh handles password-type attributes that flow through the mesh — how they are redacted at storage, in the REST API, and in the Admin UI, while remaining change-detectable so exports and delta sync keep working.

This is not the same thing as connector-credential encryption. Secret-store encryption (DPAPI / Key Vault / Vault) protects the credentials IdentityMesh uses to authenticate to source and target systems — see secrets-and-dpapi.md. This document is about password attribute values that move through the mesh as identity data (for example a user’s unicodePwd on the way from a source to Active Directory).

TL;DR

• Attribute values whose name marks them as a password — unicodePwd, anything ending in pwd, and password — are never persisted, returned, or displayed in clear text.
• Wherever such a value would appear — the stored mesh-object / management-space value, the REST API response, and the Admin UI — it is shown as the literal token ***REDACTED***.
• Change detection still works: a separate SHA-256 ContentHash is computed over the real value and stored alongside the redacted placeholder. The engine compares hashes, not clear text, so it can still tell when a password has changed and needs to be exported.
• Shipped in MSI 1.2.26256. On rollout the live database was purged of pre-existing clear-text password rows (see Rollout history).

What is protected

Redaction applies to identity attribute values that are password material flowing through the mesh, matched by attribute name:

• unicodePwd (the Active Directory password attribute)
• any attribute whose name ends in pwd
• password

These are the values that would otherwise be written into the mesh object / management-space store, echoed back by the mesh-object API, and rendered in preview and audit surfaces in the Admin UI.

Connector credentials — LDAP bind passwords, SQL passwords, OAuth client secrets, API keys — are a different concern and are not what this document covers. Those are held as encrypted secret-store blobs and referenced by a secret://… ref; see secrets-and-dpapi.md and the key-vault runbooks.

How it behaves

At storage

When a password-type attribute value is stored, the clear-text value is replaced with the token ***REDACTED***. The clear text is not written to the database.

In the REST API

Reading a mesh object through the API returns the same ***REDACTED*** token in place of any password-type attribute value. API consumers — including the preview and audit views — never receive clear text.

In the Admin UI

Every surface that displays attribute values (object detail, sync preview, audit / run history) renders the redacted token. An operator inspecting a person object sees ***REDACTED*** for the password attribute, not the value.

Change detection via ContentHash

Redacting the stored value would normally break change detection — the engine could no longer tell whether a password had changed, so it would either never export an update or churn on every run. To avoid that, a separate SHA-256 ContentHash is computed over the real value at the point it enters the mesh and stored next to the redacted placeholder.

The engine’s delta / export logic compares ContentHash values rather than the (redacted) stored value. A changed password produces a different hash, which drives a normal export; an unchanged password produces the same hash and is correctly skipped. Exports therefore still carry the correct password to the target even though the value persisted in the mesh is ***REDACTED***.

Why it matters for compliance

• No clear-text passwords at rest. Synced password material is not stored in clear text in the IdentityMesh database.
• No clear-text passwords on the audit / preview surface. The REST API and every Admin UI view show ***REDACTED***, so passwords cannot leak through preview screenshots, exported audit records, or API responses pulled by a downstream tool.
• Function preserved. Because change detection runs off the ContentHash, redaction is transparent to sync correctness — password updates still flow to the target.

This complements, rather than replaces, database-level encryption (TDE, see database-tde.md) and connector-secret encryption. TDE protects the whole database file; secret-store encryption protects connector credentials; redaction ensures the synced password attribute is never clear text in the first place.

Rollout history

Redaction shipped in MSI 1.2.26256. Because the behaviour was introduced after data had already been flowing, the live database contained pre-existing clear-text password rows written by earlier builds. On rollout those rows were purged — 49,948 clear-text password values were removed and the purge was verified to leave zero clear-text password rows behind. This is stated here as historical context for the rollout; no secret values are recorded in this document.

New deployments start with redaction already in force, so no purge is required.

Verifying redaction

An operator can confirm redaction is active without needing any special tooling:

1. Via the Admin UI. Open a mesh object that carries a password-type attribute (for example an Active Directory person with unicodePwd). Confirm the attribute value renders as ***REDACTED*** in the object detail, sync preview, and audit views.
2. Via the mesh-object API. Read the same object through the REST API and confirm the password-type attribute comes back as ***REDACTED*** rather than a clear-text value.

If either surface ever shows a clear-text password value, redaction is not being applied for that attribute — treat it as a security issue and check that the engine build is at or above MSI 1.2.26256.

Related

• secrets-and-dpapi.md — connector-credential secret store (DPAPI). Protects the credentials IdentityMesh authenticates with, not the password attributes it syncs.
• database-tde.md — encryption of the whole database at rest and in transit.