Docs

Vault and security

Where credentials live, what the server holds, and which realm is allowed to ask for what.

What it is for

Deploying to a target instance means authenticating to an instance your browser is usually not logged into. SSO governs the user interface, not the REST API, so a stored ServiceNow account works over Basic auth whoever the identity provider is.

Where the account has MFA, ServiceNow accepts the TOTP appended to the password in the same field, so the password is followed directly by the current six digits. That behaviour was measured against a live instance rather than taken from documentation.

What the server holds

Ciphertext and labels. Nothing else.

Secrets are sealed with AES-GCM under a key derived from your passphrase with PBKDF2 at 600,000 iterations. The passphrase is never stored and never sent. Only the encrypted blob and the names you gave things, the customer and the environment, ever sync.

The derived key lives in session storage owned by the extension: memory only, cleared when the browser closes, and not readable from a content script. That is a deliberate trade. A Manifest V3 worker is torn down after seconds of idle, so a key held in a plain variable would be gone before your next deploy and you would type the passphrase every single time.

Three boundaries

• The page realm never sees a secret. The vault is managed on an extension page, not in the widget. The widget shares a realm with ServiceNow's own scripts, so a password field there would be readable by the page. The bridge does not relay vault operations at all, which means the page realm cannot reach them even by asking.
• The page cannot aim a credential. It can ask for a request to be authenticated and nothing more. The worker resolves which entry applies from the request URL, so a forged message cannot point one customer's credentials at another instance, or at an identity provider.
• Every privileged call is re-checked. The worker rebuilds an allowlist from the extension's own host permissions and tests each fetch, cookie operation and tab open against it. Suffix-confusion hosts, scheme downgrades and javascript: URLs are covered by 17 tests.

Revealing an encrypted field

Unlocking a password field on a form can show the decrypted value instead of the ciphertext the platform puts in the input. It escalates nothing: the decrypt runs through the same background-script path that already required admin, and the server re-checks the dictionary first, so a one-way password column answers that it is not decryptable rather than leaking a hash.

Three rules keep the feature from becoming a leak of its own. The value never goes into the record, because writing plaintext into the input would ride along on your next Save. It is never logged, only the field's name is. And it is never cached: the overlay dies on re-lock, on Escape, when the tab is hidden, on navigation, and after 45 seconds regardless.

When a decrypt is ambiguous it says so, with an unchanged marker, instead of presenting a value as certain or hiding a good one.