Practical guide
How to Send a Password Without Putting It in Email
Keep a readable password out of an ordinary email body while retaining a simple delivery workflow.
Published: June 21, 2026
Current implementation boundary
Current Collogue links carry the encrypted payload in the URL. The browser uses Web Crypto API: PBKDF2-SHA-256 with 310,000 iterations derives a 256-bit AES-GCM key from the separately entered password, with a random 16-byte salt and a 12-byte IV. The current client has no application API request for creating, retrieving, or storing messages.
The password is not encoded in the link. The implementation does not provide one-time viewing, server-side deletion, or an expiry timer. Treat the full link as sensitive and share the password through a separate channel.
Further context
Direct answer: Create a temporary, unique password; place only that password in a Collogue message; send the private link to a verified recipient; require the password to be changed after first login; and revoke it if the link is opened unexpectedly.
The worst place for a password is often the place everyone can search forever.
Email is excellent at retention. That is normally a feature. For temporary credentials, it becomes a liability.
Do not send the user’s permanent credential.
A temporary link and a temporary password reinforce each other.
Avoid packaging an entire access guide inside the private message.
``text Temporary password: [generated value] ``
- the official login page;
- the username;
- instructions;
- support contact;
- the requirement to change the password.
For higher-risk systems, separate some context or confirm it through another channel. Do not create needless complexity for low-risk access.
- the full destination address;
- autocomplete selection;
- recipient identity;
- whether the account is shared;
- whether external forwarding is likely.
If the request arrived unexpectedly, verify it through a known channel.
This link contains your temporary password. Use the password shared separately, change the password after your first login, and contact me if either the link or password may have been disclosed.
Do not tell the recipient to paste the link into a security-checking website. That service may request it.
The delivered password should stop being valid after the recipient creates their own credential.
- the email account is later compromised;
- the link was copied;
- the sender retained the generated value;
- a notification exposed the link.
The target system, not Collogue, must enforce this behavior.
A temporary password is still a password.
Require or encourage MFA on the target account. Prefer phishing-resistant methods where available and appropriate.
Do not send all recovery factors in the same message.
- invalidate the temporary password;
- check whether the account was used;
- generate a new password;
- verify the recipient;
- create a new Collogue message;
- investigate repeated scanner behavior.
Do not resend the same password by ordinary email.
- a team needs persistent shared access;
- administrators must revoke individual access;
- access requires audit records;
- credentials rotate automatically;
- the password must remain synchronized;
- enterprise policy requires an approved vault.
The workflow is not secure because one particular link is magical. It is secure because each part has a limited job.
It can be appropriate for a verified recipient when the password is temporary and the organization understands link-scanner behavior.
That depends on risk. Separating the username may reduce convenience and may or may not create meaningful independence. Prioritize temporary credentials, recipient verification, and MFA.
Avoid it. Create a temporary, scoped account or use an approved privileged-access workflow.
Yes, when the target system supports first-login change. The delivered value should be a bootstrap credential, not a permanent shared secret.
Create a private Collogue link, send it to the verified recipient, and require the credential to change after first use.