Web App Security Zero Knowledge

One Time Password Share

Share a secret. Once. A one-time link that carries a password or an API key out of band, then destroys it.

Try it at oobsecret.com
Overview

A secret that deletes itself once it has been read.

The server never sees the key.
The secret is encrypted in the browser before anything is sent. The key lives in the link fragment, the part of a URL that browsers keep on the client and never transmit. What reaches the server is ciphertext it has no way to read, and once the view limit or the clock runs out even that is gone.

Paste a password, an API key or a token, choose how many views it survives and how long it lives, and you get a link. Send the link. The recipient opens it once, the plaintext is reassembled in their browser, and the record is deleted. There is no account to create, nothing to install, and no analytics watching.

The Problem

Credentials get pasted where they live forever.

A password goes into a Slack thread, a ticket comment or an email chain, and then it simply stays there. It gets indexed, it gets forwarded, it outlives the person who needed it, and it sits in the backups of three systems nobody thought about.

The Approach

Give the secret its own channel.

Out of band means moving the credential off the channel that needs it. One Time Password Share is that separate channel: the thread gets a link that stops working, and the secret itself was never in the thread at all.

Security Model

Designed so that trusting us is optional.

AES-256-GCM in the browser

Encryption happens client-side on the native Web Crypto API. No cryptographic library is shipped with the page, deliberately: the served code is the one part a user cannot verify, so there is as little of it as possible.

The key stays in the fragment

The key is generated in the browser and lives after the # in the link. Browsers never send that part to the server, so the stored ciphertext is useless to anyone holding only the database.

A burn that cannot double-spend

Retrieval decrements the view counter and deletes the row inside one transaction with a row lock. A failed commit rolls back rather than quietly spending a view the reader never got.

Optional passphrase

Turn it on and the key is derived from the fragment plus PBKDF2 over a passphrase you send by a different route. Someone who intercepts the link alone still has nothing.

No stored addresses

Rate limiting needs to recognise a repeat caller without keeping one. It keys on a peppered HMAC of the address rather than a plain hash, because the whole IPv4 space is small enough to enumerate against an unkeyed digest.

Config outside the web root

The database password, the pepper and the captcha secret live in a directory no vhost points at. No .htaccess mistake can expose them, because nothing served has a path to them.

What It Does

Small surface, careful edges.

Burn after N views

One view, or three, five or ten when a link has to reach a couple of people. Whichever limit is hit first, the view count or the clock, destroys the record.

Expiry on your terms

An hour, a day, a week or a month. A scheduled sweep clears anything that has run out of time, so expired rows do not linger waiting to be read.

A 1-click retrieval step

Link previews and security scanners follow URLs automatically and would otherwise spend the only view before a human saw it. An explicit reveal button stops the joke being on the sender.

Immediate deletion

The recipient can destroy the secret the moment they have copied it, instead of leaving it alive until the counter or the clock catches up.

Generators built in

Password, passphrase and client ID/secret generators live alongside the app, so a credential can be created and sent without a detour through another site.

No account, ever

Nothing to sign up for and no analytics. The fastest path from "I need to send this" to a link in the clipboard is the whole product.

Tech Stack

Boring server, careful client.

PHP (PDO) MySQL / MariaDB Web Crypto API AES-256-GCM HKDF / PBKDF2 Vanilla JavaScript Playwright Jest

No framework on either side. The client ships only the crypto it needs and nothing more, and the server is a small PHP application kept deliberately outside the document root. Playwright drives the browser tests, Jest covers the crypto module, and a release build script assembles exactly the files that go to the server.

Testimonials

What people are saying.

Marcus T.

“Dead simple, no sign-up needed. Perfect.”

Priya K.

“Clean UI, fast, does exactly what it says.”

Tom H.

“Saved me from emailing plaintext passwords ever again.”

nightowl_dev

“So much lighter than the alternatives. Loads instantly.”

Chris_Ops

“Recommended this to my whole dev team, everyone's happy with it.”

Need something handled carefully?

We build small tools where the security model is the product, not an afterthought.

Start a project