Docs / Sentinel

Know which credentials need attention.

Sentinel combines local password analysis with optional Pwned Passwords range checks.

Separate local and online checks

Sentinel analyzes supported password fields and website values through 9Core. Strength, reuse, and insecure-website analysis are local. Compromised-password status can use the network when HIBP checks is enabled.

Sentinel applies password semantics to the default schema field with the technical key password. A concealed custom field or renamed label does not automatically become a password field.

Review each finding

• Compromised: passwords found in known breaches.
• Weak: passwords that are short or predictable.
• Reused: passwords used by more than one item.
• Old: items containing a password whose item modification time is over one year old.
• Insecure Websites: website values that use http:// instead of HTTPS.

Select a finding row to open All Vaults with that Sentinel filter. The report identifies the item without displaying its password.

Understand local analysis

Local strength analysis uses zxcvbn pattern and entropy estimation. Passwords shorter than eight characters are weak, and predictable passwords can be weak even when they are longer.

Reuse analysis compares exact decrypted values across fields with the canonical password key and excludes the field currently being edited. The report does not need to display those plaintext values.

An http:// website creates an insecure-site warning unless that field has an explicit encrypted allowance. The allowance synchronizes with the field. It acknowledges a required exception and does not make HTTP secure.

Use HIBP range checks

When HIBP checks is on, 9Core:

1. Computes the password's SHA-1 hash locally.
2. Sends only the first five uppercase hexadecimal characters to the Pwned Passwords range endpoint.
3. Requests response padding and rejects responses larger than a fixed 2 MiB safety cap.
4. Compares the returned suffixes with the rest of the hash locally.

The password and complete hash are not sent. The service and network can still observe connection metadata and the five-character prefix request. Sentinel does not check email-address or account-breach APIs.

If the network request fails, online status is unknown or pending. The local fallback still applies, but failure never means the password is safe or absent from breaches.

Run manual or scheduled audits

1. Open Sentinel.
2. Wait for all visible vaults to finish.
3. Review each nonzero finding group.

Set Sentinel audit frequency to Off, Every unlock, Daily, Weekly, or Monthly. Scheduled work runs when 9Core reports that an audit is due. Last Sentinel audit shows the stored audit time or Never.

Off disables scheduled full audits, not live password-editor feedback. You can still select Run Audit manually.

Act on a finding

1. Select a finding category, then open the affected item.
2. For Compromised, Weak, Reused, or Old, change the password at the service first when possible.
3. Generate or enter the new password in 9Secure and save the item.
4. For Insecure Websites, replace http:// with the verified HTTPS address. Allow HTTP only when the service truly has no HTTPS endpoint.
5. Run another audit and confirm the finding changed.

Password editors can show strength and reuse feedback before a full audit. Do not assume every creation surface universally blocks saving a reused password. Review the result yourself.

Understand generated-password checks

During generation, a cryptographically generated password of at least 12 characters can receive immediate Success without an HIBP request. This avoids an unnecessary online check during generation.

A complete audit still uses strict checking for every stored canonical password field, including generated passwords. Generation is not permanent proof that a password has never appeared in a breach.

Protect cached audit state

Each field's Sentinel status and last-check time are encrypted locally in the vault index. Sync invalidates this per-field cache and 9Secure recomputes it. Derived report findings such as Reused and Old are not a synchronized cache.

The last full audit time and schedule metadata are installation-local configuration and do not synchronize. The searchable index is decrypted while a vault is open and is not locked-memory storage. Lock the keyring when finished and protect the device session. Reports identify affected items, but password payloads remain concealed until requested.

Handle disabled or offline checks

• HIBP checks off: local findings continue, but no current online compromised-password result is produced.
• Offline or service failure: treat compromised status as unknown or pending, not safe.
• No finding after a change: confirm the item uses its type's field with the canonical password key, save it, then run the audit again.
• Unexpected HTTP finding: verify the saved Website value and its scheme. An allowance suppresses the warning for that field but does not encrypt HTTP traffic.
• Stale audit time: unlock the required vaults, check the configured frequency, then run a manual audit.