Skip to main content

Feature

Secure Link Sharing: Getting a Secret to Someone Else

Encryption solves storage. Sharing is the harder problem, because at some point a human has to receive something — and every channel available for that is imperfect. This page is about doing it as well as the constraints allow.

Last reviewed Reviewed by Inkrypt Security Team

When you share a note, Inkrypt issues a token — a long, unguessable identifier — and serves the note at /share/<token>. The token is an address, not a key. Someone holding it can request the encrypted payload from our servers; they still need the password to turn that payload into readable text.

That separation is the entire design. It means a link leaking is bad but not immediately catastrophic, and it means the two halves can travel through two different channels.

Link format/share/<random token>
What the token grantsRetrieval of ciphertext only
What is still requiredThe note password, held only by you
Indexingnoindex, nofollow — excluded from robots.txt and the sitemap
Per-link controlsExpiry time and maximum view count

Share pages are never indexed

Share URLs are served with noindex, are disallowed in robots.txt, and never appear in our sitemap. They also carry no advertising — they are a password gate, not a content page.

The rule that matters most: split the channels

If you send the link and the password in the same message, you have built an elaborate machine that delivers a plaintext secret. Everything upstream — the encryption, the key derivation, the expiry — is bypassed by that single convenience.

Channel separation means an attacker has to compromise two independent things to get the secret. Compromising a mailbox is realistic. Compromising a mailbox and a phone simultaneously is a materially harder problem.

Workable channel pairings, roughly in order of preference.
Send the link viaSend the password viaNotes
EmailPhone call or in personBest general-purpose pairing; spoken passwords leave no written record
Work chatSMS to a known numberGood, provided the number is already known to you
Ticket or project toolPassword manager shareStrong for teams that already run a manager
EmailA second emailWeak — same mailbox, same compromise
ChatThe next message in the same chatNo separation at all; avoid
Workable channel pairings, roughly in order of preference.

A worked example

  1. Create the note

    Write the credential. Generate a four-word password in your password manager rather than inventing one.
  2. Set tight limits

    Two-hour expiry, view limit of two — one spare for a mail scanner. See self-destructing notes for why two rather than one.
  3. Send the link by email

    Say what it is and that the password follows separately. Do not describe the secret itself in the email.
  4. Call and read the password aloud

    A phone call leaves no searchable artefact. Confirm the recipient has opened the note while you are still on the call.
  5. Delete immediately

    Once confirmed, delete the note rather than waiting for expiry. Then rotate the credential on your next scheduled change if it is long-lived.

Assume it will happen eventually — a wrong autocomplete in an email client, a screenshare left running, a forwarded thread. A leaked link on its own does not expose the note, but it should still trigger a response.

  1. Delete the note immediately. This is the fastest, most complete action available and it is entirely in your control.
  2. Assume the password may have leaked too, especially if the leak was a forwarded thread that might have contained both.
  3. Rotate the underlying secret. This is the only step that actually restores your position.
  4. If the note had a view limit, check whether it had already been consumed — that tells you whether anyone fetched it.

Do not put secrets in the note name

The note name becomes the URL slug, and URLs end up in browser history, server logs, referrer headers and chat previews. /aws-prod-root-key tells an observer a great deal before anyone enters a password.

Frequently asked questions

Is the share link itself enough to read my note?

No. The link retrieves the encrypted payload; the password decrypts it in the browser. Someone with only the link holds ciphertext they cannot read — which is exactly why link and password must travel separately.

Can share links appear in Google?

No. Share pages are served with a noindex directive, are disallowed in robots.txt, and are never listed in our sitemap. They also carry no ads.

What is the safest way to send the password?

A phone call, in most situations. It leaves no searchable written record and confirms you are speaking to the right person. A password manager's built-in sharing is a strong alternative where both parties already use one.

Should I use one link for several recipients?

Prefer one note per recipient. Separate notes let you set separate expiry and view limits, and if one recipient's link leaks you can delete that note without disrupting anyone else.

What if a link is forwarded to the wrong person?

Delete the note straight away, then rotate the underlying secret. The link alone does not expose the content, but rotation is the only step that fully restores your position.

Write your first encrypted note

No account, no email address, no download. Type a note, set a password, share the link.

Open the notepad