How Credals encrypts your credentials with AES-256-GCM

Credals encrypts every credential with AES-256-GCM before it touches the database. Here is what that means in plain language, and why the plaintext of your secrets is never stored.

Ayoub Miane·Founder of Credals··2 min read
ShareLinkedInX

Credals encrypts every credential with AES-256-GCM before it reaches the database. That means the plaintext of a password, API key or token is never written to storage. The database holds only ciphertext, and decryption happens transiently, in memory, at the moment you ask to view or copy one specific value.

What AES-256-GCM is

AES-256-GCM is an authenticated encryption algorithm. AES-256 is a symmetric cipher with a 256-bit key, the same standard used to protect financial and classified data. GCM, short for Galois/Counter Mode, adds authentication on top of encryption. Each encrypted value carries an integrity tag, so if the stored ciphertext is altered in any way, decryption fails instead of silently returning corrupted data. You get confidentiality and tamper detection from one primitive.

Where the encryption happens

The encryption boundary in Credals is explicit. A credential is encrypted on the way in, before it is persisted, and decrypted only when you request that specific value. There is no code path where a plaintext secret is written to disk. This matters because a boundary you can point to is a boundary you can reason about, unlike a system where "it is encrypted somewhere" is left vague.

Why the database only stores ciphertext

If someone obtained a raw copy of the database rows, they would see encrypted blobs, not your logins. Storing ciphertext only means the value of a leaked database is dramatically lower, because the secrets inside it are unreadable without the key. The plaintext of your credentials simply does not exist at rest.

How this separates from your password

Your account password and the encryption of your stored credentials are two different concerns, and Credals keeps them separate. Authentication and sessions are handled by Supabase Auth, while the server-side encryption key that protects credential values is decoupled from your login password. Separating these means one does not become a single point of failure for the other.

What happens on the clipboard

Encryption protects data at rest, but a copied secret can still linger in the clipboard where another app might read it. Credals closes that gap by clearing copied credentials from the clipboard automatically after 60 seconds. The secret is available long enough to paste, and not much longer.

The trust surface

Credals relies on a small, named set of providers: Supabase for the database and authentication, and Vercel for hosting. A deliberately small third-party surface keeps the trust boundary easy to understand. Fewer moving parts means fewer places for data to leak, and a clearer answer to the question of who touches your data.

The takeaway

Encryption is only meaningful when you can say exactly where it applies. In Credals, the answer is concrete: AES-256-GCM, applied before storage, with a ciphertext-only database and an encryption key kept separate from your password. That is the standard every credential you save is held to.

Free while we build with users

Your clients are organized. Your credentials should be too.

Move client credentials into a vault that matches how your projects are already structured. Credals is free while we gather enough usage and feedback to shape paid plans.