How to request a password from a client

Send them a link to an encrypted form rather than asking for the password in an email. It's encrypted the moment they submit, you view it once, and it's destroyed — so it never exists as plain text.

Requesting a credential is a harder problem than sending one, and it gets less attention. When you send, you control the channel. When you ask, the client picks — and they will pick reply.

Why the obvious approaches fail

Asking by email. "Can you send over the login for your hosting?" is a question in an email client, so the answer arrives as a reply in an email client. You have now caused the exact thing you were trying to avoid, and you caused it in writing. Adding "please don't email it" rarely helps: it asks the client to do more work at the moment they're trying to be helpful, and the reply button is right there.

Asking on a call. Reading a password aloud gets it typed into someone's notes, a ticket, or a chat message to a colleague. It also has a decent chance of being wrong, which means a second call.

A form you built yourself. Better, if it's encrypted at rest, deleted after use, rate-limited and not logging submissions. That's a real amount of work to get right for something that isn't your product, and a half-built version is worse than no version because it looks trustworthy.

A shared document for them to fill in. Now the credential sits in a third party's storage indefinitely, usually with link sharing on, and the client has a standing invitation to add more.

The realistic options

Ask them to use a free one-time secret tool

Point the client at Onetimesecret or similar and ask them to send you the link.

Choose this if you need one credential from one client and don't mind the extra step. The friction is real: you're asking a non-technical person to learn a tool before they can help you, and a good proportion will reply with the password instead.

A password manager's request feature

Some password managers can collect an item from someone outside your team.

Choose this if your client already uses the same one. Across an agency's client base that's unusual, which limits it to internal use in practice.

A tool with inbound secret requests

Services built for this send the client a link to a form on your domain. They fill it in, it's encrypted on submission, you open it once. SecretWolf does this as one-off requests and as a standing portal — a permanent page you can point anyone at.

Choose this if you collect credentials regularly, or a client's security reviewer will want evidence of how you did it.

Where SecretWolf fits — and where it doesn't

A request goes out as a link to a branded form on your own subdomain or custom domain. The client types the credential in, it's encrypted immediately, and you see it once before it's destroyed. The audit trail records that the request was made and fulfilled, without ever storing the value. On the Business plan a standing portal means you can put one permanent address in your onboarding pack rather than raising a request each time.

We also put work into the request email itself, because an unexpected message asking someone to type a password into a form is behaviourally indistinguishable from phishing. It names the person who asked, carries your ticket reference when there is one, explains what will happen, and tells the recipient to check with you directly if they weren't expecting it. That last line costs a conversion occasionally and is worth it.

Where it doesn't fit. Requests are a paid feature — Free can send one-time secrets but not request them. And if you need one credential from one client, once, asking them to use a free tool is a perfectly reasonable answer that costs nothing.

In context: collecting access during onboarding, or how practices use it for gateway and payroll logins.

Questions people ask