Why we built ITBroker Secret

A password should reach the person it's meant for and then disappear. That turns out to be harder than it sounds. This page explains why, and how this site does it.

Passwords don't belong in your inbox

Every day, people send passwords, API keys and Wi-Fi codes by email, Slack, Teams and text message. It's quick, and it's a problem: those messages are kept. They sit in inboxes, chat history, backups, search indexes and synced phones for years. They also go wherever those accounts go: a forwarded thread, a compromised mailbox, a former employee's laptop. The password was needed for five minutes, but the copy lasts for years.

Secret links help, but many have gaps

The usual fix is a one-time secret link: paste the password, get a link, and the link works once. That's a big step up. But when we looked closely at how these services usually work, we kept running into the same weaknesses:

The server can read your secret. Many services encrypt secrets on their own servers, so at some point the server holds the key or the plain text. You're trusting the operator, their logs, their backups and everyone with access to them.
Link previews use up the view. Slack, Teams and Outlook open links automatically to build previews or scan for malware. If opening the link is what reveals the secret, a robot uses up the one view, and the real recipient is told the secret doesn't exist. Nobody can tell whether a person or a machine saw it.
Analytics see more than you'd expect. A tracking script on the page can record the page's full address. When the address carries the key, so does the analytics report.
Accounts and email add more copies. When a service emails the link for you, or makes you sign up first, it adds another party and another copy.
You don't know what happened. Did the right person open it? Did someone else? Often there's no way to tell.

So we built our own

We used a hosted secret-sharing service for years. When it came time to replace it, we set one rule: the people running the service, which means us, must not be able to read what you share, even if we wanted to. ITBroker Secret is the result. It's deliberately small and does one job carefully.

How it works

Your secret is encrypted before it leaves your device. Your browser makes a random 256-bit key and encrypts the secret with AES-256-GCM. Only the encrypted data, which looks like random noise, is sent to us.
The key travels in the link, never to our server. A link looks like secret.itbroker.com/s/Ab3…#Xy9…. Everything after the # is the key. Browsers never send that part of an address to a website's server, so we never receive it.
You can add a password. Your browser mixes it into the key (PBKDF2-SHA256, 600,000 rounds), so the link alone isn't enough. Send the password a different way, for example the link by email and the password by phone.
Opening the link doesn't reveal anything. The recipient sees a Reveal secret button. Clicking it runs a quick human check and proves their browser has the full link. Only then does our server send back the encrypted data, which their browser decrypts.
Then it's gone. When the last allowed view is used, the encrypted data is deleted immediately. If nobody opens it, it's deleted when it expires, after 1 hour to 7 days, whichever you chose.

What makes it different

We can't read your secrets. This isn't a promise not to look: we never have the key. A full copy of our storage would be nothing but encrypted data.
Link previews can't use up a view. A scanner can load the page, but it can't click Reveal and pass the human check, so the view is saved for the person you sent it to.
Knowing the address isn't enough. Every secret has a random ID, but opening it or using up a view needs proof that comes from the full link. Someone who sees only the ID, for example in a log, can't open the secret or destroy it.
One view means one view. Each secret is stored on its own and handles one request at a time, so two people clicking at the same moment can't both get it.
You can see what happened. You get a private status link that shows whether and when the secret was viewed, with a button to delete it early if you sent it to the wrong place. If your recipient says the link didn't work but your status link shows a view, you know to change the password.
A wrong password locks the secret instead of destroying it. Five wrong guesses lock it for 30 minutes. A typo doesn't cost your recipient the secret, and guessing goes nowhere.
No accounts and no email. There's nothing to sign up for, and we never send email for you. You paste the link wherever you already talk to the person.
Strong passwords are built in. The generator makes random, memorable or PIN passwords and puts them straight into a secret. They aren't shown on screen unless you choose to see them.

What we don't collect

No tracking scripts. There's no analytics, advertising or tracking code on this site. The only outside script is Cloudflare Turnstile, the human check.
No cookies. This site doesn't set any.
No accounts. We don't ask for names or email addresses.
No content in logs. We never log what's sent to us, and detailed request logging is switched off.

Here's what we do keep, all of it on our servers, never in your browser:

For each active secret: the encrypted data, a few random values needed to decrypt it with the right key, one-way fingerprints that let us check the share and status links without storing them, the number of views left, and timestamps. After the last view, the encrypted data is deleted. A record with no content stays until the original expiry time so your status link keeps working.
Anonymous counts: how many secrets are created, opened, deleted or locked. These are tallies only, with no secret IDs, links, keys, contents or IP addresses attached.

Like any website, the site runs on a hosting provider, Cloudflare. Cloudflare sees connection details such as IP addresses so it can deliver the page and enforce rate limits. We don't store them.

Why you can trust it

You shouldn't have to take our word for any of this, and you don't have to.

Check it yourself. Open your browser's developer tools, switch to the Network tab and create a secret. The request to our server contains only scrambled data. Then look at the link: the key sits after the #, the part your browser never sends.
The page is locked down. A strict Content Security Policy tells your browser to run only our own scripts and the human check, and to talk only to our own server. If anything tried to add a tracking script, your browser would refuse to run it.
The cryptography is standard and well reviewed. Everything uses your browser's built-in Web Crypto: AES-256-GCM, HKDF, PBKDF2 and SHA-256. We didn't invent any encryption.
There's less to go wrong. There's no accounts database, no email system, no file uploads and no outside code beyond the human check. Expired secrets are deleted, not archived.
You know who runs it. ITBroker built this and runs it on Cloudflare's network. It's the same team you already work with.

What it can't protect against

Being clear about the limits is part of earning trust:

Anyone who has the full link, plus the password if you set one, can open the secret. Send it only to the right person, and add a password for anything important.
If someone intercepts the link and opens it first, your recipient will see "This secret isn't available" and your status link will show the view. Treat the secret as exposed and change it.
It can't protect a device that's already compromised, whether it's yours or the recipient's.
Once revealed, the secret is in the recipient's hands. They should save it in a password manager, not paste it back into email.
Secrets are text only, up to 10,000 characters. You can't attach files.

Questions and reports

To report misuse of this site or a security problem, email abuse@itbroker.com. Security researchers can also find our contact details in security.txt.

Share a secret