What our database actually stores (spoiler: ciphertext)
We pulled a real row from production. Here's exactly what an attacker — or a curious engineer — would see if they queried our credentials table.
On our security page, we don’t use sanitized mockups or idealized marketing diagrams. We show you the actual database rows from our production environment. We believe that if you’re trusting us with your company’s access keys, you shouldn't have to wonder how we’re handling the "at-rest" part of the equation.
Every field that touches user data—Title, Username, Password, Email, URL, and Notes—is stored as an opaque, high-entropy Base64 ciphertext blob.
The Only Metadata We Keep
We’ve aggressively minimized our database footprint to the bare essentials required for sync and integrity. Our server only knows:
- Row IDs: For database indexing.
- Timestamps: To handle synchronization and version conflicts.
created_by/project_idReferences: To ensure the right encrypted blobs reach the right authorized users.
That is the extent of our "knowledge." Nothing about the credential itself leaks to the infrastructure. Not the name of the service, not the username, and—crucially—not even the original length of your data.
The Myth of Length-Leakage
A common weakness in modern encryption is "Traffic Analysis" or "Length Analysis," where an attacker guesses the content based on the size of the ciphertext.
We use XChaCha20-Poly1305 (via Libsodium). As a stream cipher with a 16-byte Poly1305 MAC tag, the ciphertext is always exactly the length of the plaintext plus the tag overhead. However, we go a step further: by utilizing authenticated encryption, we ensure that even the structure of the data is wrapped in a layer of bit-level noise. To anyone without the key, a 12-character password and a 12-character note look identical: like a random string of digital dust.
Why We Publish the Raw Rows
In the security world, "Trust us" is not a security model; it’s a vulnerability. Most companies hide their database schema behind a veil of "proprietary secrets." We find that approach patronizing. By showing the raw ciphertext, we offer the closest thing to a "Live Audit" possible.
You can see for yourself:
- No Identifiable Patterns: There are no repeating headers or common prefixes that suggest a weak or "static" encryption key.
- Total Context Isolation: Even if an attacker gained "Superuser" access to our Postgres instance, they would be looking at a digital graveyard. Without the 3-word mnemonic—which exists only in your mind and your browser's RAM—those rows stay as they are: mathematically unreadable.
We built this platform for the "Paranoid Engineer"—the one who has spent 20 years seeing how easily servers are compromised. We assume our server is a compromised environment. That’s why we make sure there’s nothing there worth stealing.
