Question 1

What happens when someone opens my link?

Accepted Answer

The recipient's browser fetches the ciphertext from the server and decrypts it locally using the key fragment in the URL. The server then permanently marks the secret as opened and destroyed. After that point the link is dead — no further retrieval is possible.

Question 2

Can I open the link myself to check it worked?

Accepted Answer

No. The first successful retrieval burns the secret. If you open your own link, the recipient will get an "already opened" error. Use the label field to annotate what the secret is so you don't need to verify it yourself.

Question 3

What is the difference between Direct share and Inbound request?

Accepted Answer

Direct share is for when you already have the secret and want to send it. You encrypt it, generate a link, and send that link to the recipient. Inbound request is for when you need someone to send you a secret — you generate a request page, share that URL, and the other person submits the secret through it. You then receive a reveal link to open.

Question 4

What does the passphrase do and when should I use it?

Accepted Answer

A passphrase adds a second encryption layer on top of the URL key. Even if the link is intercepted, the attacker cannot decrypt the secret without also knowing the passphrase. Use it when the communication channel you're using to send the link is not fully trusted — for example, email. Send the passphrase through a different channel, like a phone call or a separate messaging app.

Question 5

What if the link expires before the recipient opens it?

Accepted Answer

The link becomes invalid and the secret is permanently inaccessible. You'll need to create a new one. Choose a longer TTL (up to 7 days) if the recipient may not open it immediately.

Question 6

Can I cancel a secret after sending it?

Accepted Answer

Yes. When you create a secret, a Destroy button appears next to the share link. Clicking it immediately and permanently destroys the secret — the link becomes invalid before anyone can open it.

Question 7

Is there a size limit for secrets?

Accepted Answer

Secrets are capped at 48 KB of plaintext. This is more than enough for any credential, API key, certificate, or recovery code. Cinderpass is not designed for transferring files.

Question 8

Does Cinderpass ever see my secret?

Accepted Answer

No. Encryption happens entirely in your browser before anything is sent to the server. The server only stores ciphertext — the encrypted output. Without the decryption key, which never leaves your browser, the ciphertext is unreadable.

Question 9

Where is the decryption key stored?

Accepted Answer

The key fragment is placed in the URL after the # character (the "hash" or "fragment"). Browsers intentionally do not include the fragment in HTTP requests, so it is never transmitted to the Cinderpass server. It exists only in the share link itself.

Question 10

How is the decryption key generated?

Accepted Answer

Cinderpass generates a fresh random 256-bit key in your browser using the Web Crypto API's cryptographically secure random number generator (`crypto.getRandomValues`). That random key is used for AES-256-GCM encryption before anything is sent to the server. If you add a passphrase, it does not replace the random key — it only protects the key fragment in the link with an additional client-side transformation.

Question 11

What happens if someone intercepts the link in transit?

Accepted Answer

If the link is intercepted and opened before the intended recipient, the secret is burned on first open and the recipient will see an "already opened" error — alerting them that something went wrong. A passphrase provides an additional layer: even with the link, the attacker cannot decrypt without the passphrase.

Question 12

How strong is the encryption?

Accepted Answer

Secrets are encrypted with AES-256-GCM using a 256-bit key generated by the browser's cryptographically secure random number generator. AES-256-GCM is an authenticated cipher — it detects any tampering with the ciphertext. This is the same algorithm used by TLS 1.3 and is considered secure against all known attacks including quantum computing threats in the near term.

Question 13

What does the passphrase protect against specifically?

Accepted Answer

The passphrase is derived using PBKDF2 with SHA-256 and 120,000 iterations, producing a second key that is XOR-applied to the main key. The derived verifier is stored server-side so the passphrase can be checked without burning the secret. A wrong passphrase increments a per-secret attempt counter — after 5 failures the secret is permanently locked.

Question 14

Can Cinderpass employees read my secrets?

Accepted Answer

Not passively — the decryption key is in the URL fragment, which browsers never include in HTTP requests, so it is never transmitted to the server. The server stores only ciphertext. However, because the server also serves the JavaScript that runs in your browser, the security model depends on that code being what is publicly published on GitHub. A malicious or compromised server could serve modified JavaScript that exfiltrates the key. This is why the source code is open and every deployed build is linked to a specific commit — so you can verify what is actually running.

Question 15

What if two people open the link at the same time?

Accepted Answer

Only one request can succeed. The burn step is an atomic database write that filters on status = ACTIVE. Whichever request commits first wins; the second sees count = 0 and gets an "already opened" error. The ciphertext is only returned inside the same transaction that marks the secret as destroyed.

Question 16

Has Cinderpass been independently audited?

Accepted Answer

Not yet. An independent security review is on the roadmap. In the meantime, the full source code is publicly available and the deployed build is linked to a specific commit so anyone can verify the code running in production matches what is in the repository.

Question 17

How do I know the deployed app matches the open-source code?

Accepted Answer

The footer of every page shows a short commit hash that links directly to the corresponding commit on GitHub. The GET /api/version endpoint returns the full commit SHA and build timestamp in JSON. You can compare these against the public repository to verify the deployed code.

Question 18

Can I self-host Cinderpass?

Accepted Answer

Yes. Cinderpass is a standard Next.js application backed by PostgreSQL. Clone the repository, set the three environment variables in .env.example, run the Prisma migrations, and deploy anywhere that runs Node.js. Vercel with a Postgres add-on is the fastest path.

Question 19

Is the source code open?

Accepted Answer

Yes. The full source is available at github.com/eleco/cinderpass under the MIT licence. You are free to inspect, fork, self-host, or contribute.

Question 20

What data does Cinderpass store?

Accepted Answer

For each secret: the ciphertext, IV, algorithm identifier, a label (if provided), expiry timestamp, creation timestamp, status, and — when a passphrase is used — a derived verifier and salt. The server never stores plaintext, the decryption key, or the passphrase itself.

Question 21

How long is data retained?

Accepted Answer

Secrets are stored until their TTL expires (maximum 7 days) or until they are opened or destroyed. An hourly background job marks expired records. Opened and destroyed records remain in the database as audit rows but the ciphertext is inaccessible by design — the key needed to decrypt it was never stored.

Question 22

Is any personal information collected?

Accepted Answer

No accounts, no email addresses, no tracking. IP addresses may appear in server access logs at the infrastructure level (Vercel, Neon) for standard operational purposes, but Cinderpass itself does not store or log IP addresses.

Frequently asked questions

Using the app

Security

Trust & verification

Data & privacy