StretchVault is built so that a secret is protected at every stage — while it's stored, while it's being analyzed, and while it's being used. This article explains, in plain language, the protections behind the app so you can trust it and explain it to stakeholders.
Encrypted at rest with AES-256-GCM
Every secret value you save is encrypted with AES-256-GCM before it's written to the database. AES-256 is a widely trusted, industry-standard encryption algorithm; the GCM mode adds an authentication tag that detects any tampering with the stored data. In practice this means the raw contents of the database are ciphertext — unreadable without the encryption key — and any corruption or tampering is caught on decryption rather than silently returning a wrong value.
Each secret is encrypted with a fresh random initialization value, so even two identical passwords produce different ciphertext on disk. Plaintext is never written to logs or stored anywhere; only the ciphertext, its initialization value, and its authentication tag are kept.
Secrets are never in list views
The most important design decision in StretchVault is that secret values are excluded from all list reads. When you browse the Items tab, load a dashboard, run a search, or pull a report, the response contains only metadata — title, username, URL, tags, strength, exposure — and never the secret. The ciphertext isn't even sent to your browser in those views.
The only way to obtain a secret is to reveal a single item deliberately, which decrypts just that one value at that one moment and records the event in the access log. The upshot: a leaked screenshot, an over-broad export, or a curious glance at someone's screen never exposes a password.
Reuse detection without exposing plaintext
StretchVault can tell you when the same secret is used on two items — but it does this without ever comparing the plaintext. When a secret is saved, StretchVault computes a fingerprint: a one-way SHA-256 hash of the value. A fingerprint can't be reversed back into the secret, but two identical secrets always produce the same fingerprint. Watchtower and Breach-watch detect reuse by comparing fingerprints, so your actual passwords are never gathered together or sent anywhere to be checked.
The same principle applies to security analysis: the audit and rotation features operate on fingerprints and cached posture data (strength score, age, flags), so plaintext never leaves the secure boundary for those computations.
The encryption key and the Health tab
All of this depends on a master encryption key being configured for your workspace. When it is, the Health tab shows encryption as enabled and StretchVault will accept secret-bearing saves. When it isn't, StretchVault deliberately refuses to store secrets rather than save them unprotected — you'll see a "StretchVault encryption is not configured" message. This fail-safe guarantees a secret is never written in the clear.
A realistic example
Meridian Studio's owner is asked by a security-conscious client how their passwords are protected. The owner explains: secrets are encrypted with AES-256-GCM before storage; nobody — not even an admin browsing the item list — sees a password without performing a logged reveal; reuse is detected by one-way fingerprints, so the studio never assembles the client's plaintext passwords in one place; and if encryption were ever unavailable, the system would refuse to store new secrets rather than expose them. The client is satisfied because each claim maps to a concrete mechanism, not a marketing promise.
What this means for you
- You can safely store your most sensitive values, knowing they're encrypted and access-controlled.
- You can share and audit confidently, because every reveal and grant is recorded.
- You can answer security questionnaires with specifics: AES-256-GCM at rest, metadata-only reads, one-way fingerprints for reuse, and a fail-safe that refuses unencrypted storage.
Tips
- Check the Health tab periodically to confirm encryption stays enabled — it's your one-glance assurance that protections are active.
- Pair StretchVault's protections with 2FA on the underlying accounts; encryption protects the stored value, and 2FA protects the account even if a value leaks.
- When documenting security for clients or compliance, cite the specific mechanisms above rather than generic "bank-grade encryption" language.
FAQ
Can StretchVault staff or admins read my secrets from the database? The database holds only ciphertext; reading a secret requires decryption via a reveal, which is logged. Admins can reveal within vaults they administer, and those reveals are recorded.
What happens to my secrets if encryption is turned off? Existing ciphertext stays encrypted, but StretchVault refuses to store new secrets until encryption is available again — it will not save them unprotected.
Is the same encryption used for every item type? Yes. Logins, notes, servers, API keys, and payment cards are all encrypted identically with AES-256-GCM.
Was this helpful?
Help us improve this article
Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.