Are one-time password links safe?

They are considerably safer than sending a password in a chat message or email, because the secret stops existing after it is read rather than sitting in a thread indefinitely. Safety depends on the service: look for encryption performed in your browser, a key that is never sent to the server, and genuine deletion rather than a hidden flag. Treat the link itself as sensitive, because anyone holding the full URL can open it.

How is this different from just emailing a password?

An emailed password stays in the inbox, the sent folder, the mail server and every backup of them, readable by anyone who later gains access to any of those. A one-time link is readable once and then gone, which limits exposure to a single moment rather than to the lifetime of the mailbox.

What happens if the recipient never opens the link?

Nothing is left behind. The secret is deleted when its time limit expires, whether or not it was ever read, and the link then shows only that the secret is gone.

Can the service read my password?

With OOBSecret, no. The secret is encrypted in your browser and the decryption key is placed in the part of the URL after the hash symbol, which browsers never transmit to a server. What is stored is ciphertext with no key alongside it.

Should I send the link and the passphrase together?

No. If you add a passphrase, send it by a different route - a text message, a phone call, or in person. Putting both in the same message means one compromised channel gives up both halves, which removes the benefit of having a passphrase at all.

What is a one-time password link?

Q: What is a one-time password link?

A one-time password link is a URL that displays a password, API key or other secret exactly once, then permanently deletes it. The secret is encrypted before storage, and the link expires after a set number of views or a set period, so it cannot be read later by anyone who finds the message it was sent in.

A one-time password link is a URL that shows a secret exactly once and then deletes it permanently. You paste a password, API key or recovery code into a service, receive a link, and send that link to whoever needs it. They open it, read the secret, and the record is destroyed. Opening the same link again shows nothing.

You will see the same idea under several names - one-time secret link, burn after reading link, self-destructing link, ephemeral secret. They describe the same mechanism.

The problem they solve

Passwords get shared constantly, and almost always through channels never designed to hold them. A database password ends up in a ticket. An API key goes into a team channel. A recovery code is emailed "just for now".

The issue is not that those channels are unencrypted - most are encrypted in transit. The issue is that they are durable and broad. A message in a team channel stays readable by everyone who joins afterwards, is indexed by search, is copied into backups, and is exported wholesale if the account is ever compromised. The credential outlives the reason it was shared, sitting in a place chosen for convenience rather than for keeping secrets.

A one-time link narrows that exposure from months to minutes.

How a one-time password link works

Good implementations follow roughly the same sequence:

You enter the secret. On a well-built service this is encrypted in your browser before anything is transmitted.
The ciphertext is stored, the key is not. The decryption key goes into the URL fragment - the part after the # - which browsers are specified never to send to a server.
You get a link and send it on. Ideally through a different channel from the one that needs the credential.
The recipient opens it. Their browser fetches the ciphertext and decrypts it locally using the key from the fragment.
The record is destroyed. Once the view limit or the clock is reached, the row is deleted rather than flagged.

The detail that matters most is the second step. If the key travels to the server, the service can read every secret it holds, and so can anyone who obtains its database. If the key stays in the fragment, the stored data is useless on its own.

What to look for in a service

Browser-side encryption. If the secret is encrypted on the server, the server saw it in plain text first.
A key that is never transmitted. Usually implemented with the URL fragment. Ask where the key lives.
Real deletion. A status column set to "viewed" is not deletion, and the data is still there.
Both kinds of limit. A view count and a clock, so an unread secret does not sit indefinitely.
An optional passphrase. This is what makes the link alone insufficient.
No account requirement. Anything that adds friction loses to the habit of pasting the password into chat.

When to use one

They fit any handover that is one-off and time-bounded:

Giving a contractor an API key for a job starting today.
Handing over an account during onboarding or offboarding.
Sending a temporary password that will be changed on first login.
Passing a recovery code or a certificate to a colleague.
Sharing a credential with a client who is not in your password manager.

They are not a substitute for a password manager. A manager is for credentials your team holds continuously; a one-time link is for moving one credential from one person to another. Use both, for different jobs - there is more on choosing between them here.

The mistake worth avoiding

The most common error is pasting the one-time link into the same channel you were trying to keep the password out of. The link is a bearer credential: anyone holding the full URL can open it. Putting it somewhere durable and widely readable recreates the original problem, with an extra step.

Send the link through a channel the credential does not belong to, and if the secret is valuable, add a passphrase and send that by a third route. An attacker then has to compromise two unrelated channels rather than one.

One useful side effect

Because the link works only once, interception becomes visible. If your colleague opens it and is told the secret has already been viewed, either a preview bot fetched it or somebody else read it first. Either way you have learned something a plain email would never have told you, and you can rotate the credential before it is used.