Version 2.4 — © 2025–2026 Sansyourways Last Updated: September 2026

SPM (Sans Password Manager) is a privacy-focused, offline, fully client-side encrypted application. This document contains the security policy for vulnerability reporting, responsible disclosure, and usage expectations.

SPM is designed around the following core principles:

• Offline-first — no servers, no cloud sync, no telemetry.
• Zero data collection — all vault data stays on the user's device.
• Strong encryption — vault data is sealed with AES-256-CTR and authenticated with HMAC-SHA256 (encrypt-then-MAC). The master password is stretched with scrypt (n=65536, r=8, p=1); the vault key it unwraps is 256 random bits and is not stretched, because it has nothing to stretch. A vault may instead be sealed with Argon2id (m=65536 KiB, t=3, p=1) where a backend is present that keeps the master password off the argument vector — the argon2 reference CLI (password on stdin) or the argon2-cffi module (in process); this is opt-in per vault (spm kdf argon2id) and recorded in the vault header, and scrypt remains the default because it is reachable on every platform SPM supports. SPM never puts the password on argv to derive a key (openssl's kdf app is not used for that reason), and never silently reseals an Argon2id vault under scrypt. Vaults written before 4.0.0 are GnuPG symmetric AES-256 and are still read; they upgrade in place on their next write, keeping the same vault key.
• User-controlled keys — the user is the sole owner of all keys and passwords.
• User-controlled recovery — recovery requires either the locally generated RSA private key and recovery blob, or a registered hardware security key (which resets the master password through the same WebAuthn PRF secret that opens the vault); the developer can recover neither.
• Crash-safe writes — ciphertext is staged and atomically installed, with a last-known-good encrypted backup.
• Concurrent-write protection — CLI and web mutations share one advisory lock on every supported platform. flock(1) is used where it exists; macOS does not ship it, so the CLI takes the same lock through python3's fcntl, which is the primitive the dashboard has always used, so the two exclude each other. The kernel releases the lock when the last holder exits, so a killed process leaves nothing to clean up.
• Local-first extensions — history, backups, attachments, and sync contain encrypted vault material; the browser extension talks only to a local native-messaging host, and its autofill, password capture, password generation, one-time-code fill, and look-alike/phishing warning are all explicit, hostname-bound, and gated to an unlocked session.
• Platform-owned passkeys — SPM stores passkey metadata, never private passkey key material.

Core vault operations are offline. The optional updater contacts GitHub Releases, and SPM Dashboard serves the local vault UI on the address selected by the user. The optional breach review contacts the Pwned Passwords range API only after an explicit CLI or Dashboard action; SHA-1 is computed locally and only a five-character prefix is sent, with padded responses requested. Passwords and full hashes are never transmitted or persisted. The startup release check is off unless the user enables it, and downloaded releases are SHA-256 verified and syntax-checked before they replace the installed script, which is swapped in by rename so a running instance is never rewritten underneath itself.

SPM is open-source under Apache-2.0. Security fixes are maintained for the latest stable official release; forks and modified distributions should obtain support from their respective maintainers.

If you discover a potential security issue, follow these rules:

• Report it privately and directly.
• Provide steps to reproduce.
• Provide your environment details (OS, version, architecture).
• Wait for confirmation before sharing further details.

• Publicly disclose the vulnerability.
• Post the issue in GitHub issues.
• Share vaults, passwords, or private keys.
• Upload sensitive data for testing.
• Test systems, accounts, or data you do not own or lack authorization to assess.

sans@silentprotocol.top

You should receive acknowledgment within 3 business days.

When reporting, attach:

• A clear description of the issue
• Steps to reproduce
• SPM version
• Your OS and setup
• Expected behavior vs actual behavior
• Logs only if safe (no sensitive data)

Do not send:

• Real vaults
• Real passwords
• Master password
• Private keys
• Screenshots containing sensitive entries

The following are considered in-scope for reporting:

• Encryption implementation bugs
• File corruption or integrity failures
• Web mode security concerns
• Local process access vulnerabilities
• Cryptographic misuse
• Privilege escalation inside SPM
• Bundle/backup handling vulnerabilities

The following are out of scope:

• Lost master passwords
• User-caused key loss
• Device compromise (malware/virus/root)
• Issues found only in an independently modified distribution
• Vault recovery requests
• Cloud leakage (SPM never uploads data)
• Brute-forcing encrypted vaults
• Unofficial extensions or scripts

The project uses the following best-effort response targets:

Targets may change with complexity, maintainer availability, or coordination needs. The reporter will receive material status updates when a target changes. Lower-severity findings are prioritized into a planned release based on impact and available maintenance capacity.

Valid reports are investigated privately, credited if requested, and kept confidential until a fix or coordinated disclosure when reasonably possible.

Good-faith source review and security research are welcome. Do not access data, devices, or services without authorization, and coordinate disclosure of unfixed vulnerabilities that could put users at risk.

Users are fully responsible for:

• Protecting their master password
• Storing backups securely
• Managing encryption keys
• Protecting their device from malware
• Securing their filesystem permissions
• Anything reachable from the internet, including an SPM Dashboard instance published on a domain

Because SPM does not collect data or hold keys, the developer cannot restore lost vaults.

Publishing SPM Dashboard on a domain widens the trust boundary considerably. The vault stays bound to 127.0.0.1 behind nginx, so nginx and TLS are the only things standing between the internet and a master-password prompt. Prefer a DNS-only record: a CDN or reverse proxy that terminates TLS at its own edge can read every request in plaintext, the login POST included. Certificates are logged to public Certificate Transparency, so the hostname is discoverable — obscurity is not part of the protection.

Security issues: sans@silentprotocol.top General support: sans@silentprotocol.top Trademark and partnership questions: sans@silentprotocol.top

Copyright 2025–2026 Sansyourways and contributors.