How Password.link Secret Request Links Work for Collecting Sensitive Data

Updated

Password.link's Secret Request feature flips the usual one-time-link flow: instead of you sending a secret outward, you create a request link and send it to the person whose data you need. That recipient submits passwords, API keys, or files through a one-time link that only you can open. Use it when you need credentials or documents from clients, users, or colleagues but don't want them sent over email or chat in plain form.

What a Secret Request link is

A normal Password.link share works like this: you enter a secret, the browser encrypts it, and you send the resulting self-destructing link to a recipient. A Secret Request reverses the direction. You generate a link that invites someone to submit information; when they do, the data is encrypted and packaged into a one-time link addressed to you.

The site describes it as working "the same way as sharing data with a one-time link, except that the end result is that you will receive the one-time link containing the data you have requested." The intended uses it names are collecting credentials or documents from clients and users.

Step by step

  1. Create the request. In your Password.link account, start a Secret Request link rather than a standard share link. The site presents Send, Receive, and Chat as the three main modes; Receive is the Secret Request path.
  2. Send the request link to the person you need data from. Any normal channel works for delivering the link itself, since the link carries no secret — it only opens a submission form.
  3. The recipient submits their data. Their browser encrypts the secret before it leaves their machine, consistent with the zero-knowledge design described on the site.
  4. You receive a one-time link. Open it once to retrieve the submitted credentials or files. As with all Password.link links, it self-destructs after a single view by default.

What you can configure

Password.link states that each link supports settings including expiration time, an optional password, CAPTCHA, and how many times the link can be opened. These settings apply to the link you generate, so you can tighten access on the retrieval side — for example, requiring a password you share with the recipient through a separate channel, or shortening the expiration window.

Where the security properties come from

  • Encryption happens in the browser. The site says secrets are encrypted in the browser before leaving, using AES-256-GCM, and describes the service as zero-knowledge.
  • One-time viewing. Links self-destruct after a single view, which limits exposure if a link is forwarded or intercepted.
  • EU hosting. The site states data is EU hosted.
  • Track record. Password.link says it has been trusted since 2016 and lists teams such as BioNTech as users.

These claims come from the vendor's own pages; they describe the design rather than an independent audit, so weigh them accordingly for high-sensitivity use.

When Secret Request is the right tool

Choose it when the data flow is inbound and one-off: onboarding a client who needs to hand over account credentials, collecting an API key from a contractor, or receiving a signed document you'd rather not have sitting in an inbox. For outbound sharing — sending a password to a colleague — use the standard one-time link instead. For back-and-forth sensitive discussion, the site offers an end-to-end encrypted chat that disappears when closed.

Practical caveats

  • Account limits. The site's interface shows a message that a limit for new Secrets can be reached, with registered users able to create more. Creating an account is described as free with no credit card required, and registration unlocks features such as attachments, branding, and notifications. Check the Plans page for current tiers before relying on volume use.
  • Delivery of the retrieval password. If you protect the returned link with a password, send that password through a different channel than the request link itself.
  • Recipient cooperation. The security depends on the recipient submitting through your link rather than emailing the data directly, so say so explicitly in your request message.