Watchtower

Watchtower continuously analyzes your vault and surfaces problems before they bite. It’s free, it runs on every account type, and it can notify you when new alerts appear.

The checks at a glance

The checks in detail

Pwned passwords

Every password is checked against Have I Been Pwned, the public corpus of real-world breach data. Keyguard hashes the password with SHA-1 and sends only the first five characters of the hash to the service; the actual comparison happens on your device (see privacy). A match means the exact password circulates in attackers’ cracking lists — no matter how strong it looks.

Example: Summer2019! passes a complexity rule, yet appears in known breaches thousands of times. Watchtower flags it; replace it with a generated password.

Vulnerable accounts

Keyguard compares your logins’ websites against HIBP’s public breach catalog and flags items whose site suffered a breach since you last changed that password — the signal that your credentials may be part of the spill.

Example: a forum you use was breached this January, and your password there dates from two years earlier — rotate it, and anywhere it was reused.

Reused passwords

Logins are grouped by their exact password; any password shared by two or more items is flagged. One breached site shouldn’t unlock the others.

Example: the same password protects your email and a shopping site — when the shop leaks it, the email follows.

Weak passwords & weak SSH keys

Password strength is estimated with zxcvbn, which models realistic guessing attacks; passwords scoring weak are flagged. SSH keys are checked for weak key length — RSA keys under 2048 bits are flagged (Ed25519 keys are not). The weak-password check is the one alert that cannot be ignored per item.

Example: dragon99 rates as guessable in minutes despite meeting an “8 characters with digits” policy.

Unusable GPG keys

Every GPG key is checked for a valid public key, a fingerprint that matches the stored key material, and usable signing or decryption material. Keyguard also flags revoked or expired keys and missing or inconsistent GPG agent metadata.

Example: your encryption subkey expired last month — mail encrypted to the old subkey still opens, but nobody can encrypt to you until you extend or replace it.

Weak GPG keys

The primary key and every subkey are checked for weak or legacy cryptography: RSA shorter than 2048 bits and the legacy DSA and ElGamal algorithms are flagged. Modern Ed25519 / Curve25519 keys pass.

Example: a 1024-bit RSA key generated a decade ago still signs fine, but its strength is well below current recommendations — generate a replacement and revoke the old key.

GPG key publishing

Watches the keyserver status recorded for each key and flags the ones needing attention: never checked, not found on the keyserver, found but the identity is unverified, revoked, or stale — verified, but not re-checked in over 30 days. Fix a finding by uploading, verifying, or refreshing the key from the item, or let the auto-refresh worker keep the status current.

Example: you rotated your key but never published the new one — correspondents fetching your key by email still get the old, soon-to-expire key.

Inactive two-factor authentication

Your login URLs are matched — by domain, honoring equivalent domains — against a directory bundled with the app of sites known to support an authenticator-app (TOTP) second factor (powered by 2factorauth). A match is flagged unless the item already carries a one-time password, or signs in with a passkey and no password. Each finding links to the site’s own 2FA documentation.

Example: your domain registrar supports authenticator apps, but your login has no authenticator key — enable 2FA there and scan the QR code into the item.

Available passkeys

The same mechanism, using the bundled passkeys directory: sites that support passkey sign-in are flagged until the item holds a passkey.

Example: your cloud storage now offers passkeys — create one on your next sign-in and skip the password (and the phishing risk).

Insecure websites

Flags item URLs that still use the http:// protocol (localhost and private-network addresses like 192.168.x.x are ignored), which sends everything — including your password — unencrypted. The fix is usually as simple as editing the URL to https://.

Duplicate items

Items are compared for similarity and grouped as likely duplicates, with a configurable tolerance that ranges from near-exact matches to fuzzier grouping. Clean a group up by merging it into a single item with multi-select.

Example: two GitHub logins with the same username, one with an older password — merge them and keep the history.

Duplicate URIs

Flags an item whose URIs end up covering the same website once match detection is applied — say, example.com and www.example.com/login both matching by base domain. Removing the redundant URI keeps autofill suggestions tidy.

Broad URI match detection

The reverse problem: URIs whose match rule is looser than it needs to be, making the item show up on sites it isn’t meant for. The fix is switching that URI to a narrower match mode — host, starts-with, or exact.

Incomplete items

Heuristics for entries you probably meant to finish: a blank or placeholder name (login, todo, entry, …) or a login without a username. Items that look deliberate are left alone — API-token-style items, passkey-only logins, and items that exist to carry custom fields or attachments.

Example: an item named email holding a password but no username or website.

Expiring items

Flags payment cards that have expired or expire within the next three months, so the replacement is in your vault before the old card declines. The check refreshes daily.

Acting on alerts

Each alert links to the affected items, so fixing takes few steps: open the item, change the password (open the generator directly from the item), enable 2FA on the site, or merge duplicates.

Not every alert applies to every item: a shared throwaway account may legitimately reuse a password. You can ignore specific alert types per item to move them to the ignored list and suppress future notifications. The weak-password check is the one exception — it cannot be silenced per item.

How the checks respect your privacy

• Pwned passwords are checked against Have I Been Pwned using the k-anonymity range API: only the first five characters of the password’s SHA-1 hash ever leave your device, and the comparison happens locally. Your passwords — even hashed — are never sent anywhere.
• Vulnerable accounts are found by comparing your items against HIBP’s public breach catalog.
• Two-factor and passkey availability come from directories bundled with the app (powered by 2factorauth and the passkeys directory), so those checks involve no network requests at all.
• GPG key checks parse and evaluate your keys locally. The publishing check reads the keyserver status recorded the last time the key was verified, uploaded, or auto-refreshed; it does not contact the keyserver itself.
• Everything else — strength, reuse, duplicates, URLs, completeness — is computed on your device.