Sending Passwords by Email – Securely

#The everyday problem behind a seemingly trivial task

A colleague needs access to the reporting system, a client wants the password for an encrypted document, an external contractor requires the credentials for a staging environment. The instinctive response is almost always the same: type the password into an email and click send. The reflex is understandable, yet it is the root cause of a surprisingly large share of avoidable security incidents.

The problem is not email as such. The problem is that a password sent in plaintext, once it leaves you, slips out of your control. It then sits in several places at once, persistently and searchably. Anyone who wants to share credentials securely therefore does not need to abolish email; they need to understand what is actually protected when a message is sent – and what is not. That is the subject of this article.

• The everyday problem behind a seemingly trivial task
• Why a plaintext password in a mailbox is a liability
  • What TLS protects – and what it does not
  • Chat tools are not a secure alternative
• The underlying principle of secure password handover
• The methods compared
  • The out-of-band principle
  • Password managers with a sharing function
  • One-time links
  • End-to-end encryption and zero-knowledge
• Avoid sending altogether where you can
• Sending passwords in a GDPR-compliant way
• Checklist: handing over credentials securely
• Common mistakes
• Frequently asked questions
• Conclusion

#Why a plaintext password in a mailbox is a liability

A sent email is not a point-to-point handover. It passes through mail servers, is stored in mailboxes, captured in backups, synchronised across mobile devices and not infrequently forwarded to third parties. Each of those stations is a separate place of retention. A password you send today may still be sitting a year from now in a mailbox archive, a backup, or the cache of a long-forgotten mail client.

The real risk of a plaintext password, then, is not the moment of sending but its persistence. Three properties make email vulnerable here:

• Durability: messages are retained by default, often for years, without anyone having actively chosen to keep them.
• Duplication: sender and recipient mailbox, servers, backups, forwards – the same secret exists in many places at once.
• Searchability: an attacker who compromises a mailbox searches specifically for terms such as "password," "access" or "login," and finds them reliably.

If an attacker compromises a single mailbox – through phishing or a reused password – they inherit not only the current correspondence but every secret ever sent in plaintext. This is the mechanism by which one compromised account becomes a chain of further takeovers.

#What TLS protects – and what it does not

At this point a familiar objection arises: "But our email is encrypted." That is usually only half true. What is widespread is transport encryption (TLS), which secures the connection between mail servers. It protects the message while it is in transit – that is, against interception on the wire.

TLS does not, however, protect content at rest. Once the email has arrived in a mailbox, it sits there readable – for the recipient, for anyone who gains access to that mailbox, and for the systems that store and back it up. Transport encryption is necessary, but it is not end-to-end encryption and it does not solve the persistence problem. A password written in plaintext in the body of a message is just as exposed after delivery as before.

#Chat tools are not a secure alternative

Sending passwords through Slack, Microsoft Teams or WhatsApp instead of email merely relocates the problem. Corporate chat tools log messages by default, keep them searchable and are subject to administrative access and export. A password in a team channel is visible to all current and future members of that channel; a password in a direct message remains in the history until someone actively deletes it – if the retention policy permits that at all.

Even where transport encryption exists, the content remains stored server-side or in the conversation history. The rule of thumb is therefore channel-independent: a secret that lands in a searchable, persistent history is no longer a secret.

#The underlying principle of secure password handover

From these weaknesses one can derive what a secure password handover must achieve. Three principles carry most of the suitable methods:

1. Separation. The secret and the context it belongs to do not travel together. Sending the login name and the password over the same channel hands an attacker both at once.
2. Transience. The secret exists only as long as it is needed. After retrieval or expiry it disappears rather than lingering indefinitely.
3. Zero-knowledge. The service used for the handover cannot read the content itself. The secret is encrypted before it leaves the sender, and only the recipient holds the key.

These three principles do not conflict with email – they complement it. Email remains the convenient handover channel; it simply no longer carries the password itself, but a reference to it that is worthless on its own once it has been redeemed or has expired.

#The methods compared

There is no single correct method, only suitability by context. The overview below places the common options in relation to one another.

#The out-of-band principle

The classic, low-effort improvement is separation across two channels: the login name goes by email, the password by another route, such as a phone call or text message. An attacker who controls only the mailbox then holds just one half.

The method is better than nothing, but it has limits. The password read out over the phone can be written down; the text message remains on the device; and the approach scales poorly if you hand over credentials regularly or to many recipients. It addresses separation, but not persistence.

#Password managers with a sharing function

Within a team or organisation, a password manager is the most robust instrument. Solutions such as Bitwarden, 1Password or a shared KeePass database let you release credentials without ever sending them in plaintext. The recipient sees the password in an encrypted vault, not in a mailbox.

The limitation is organisational: this sharing works reliably only if both sides use the same or a compatible manager. For handover to external clients, public authorities or one-off contacts who share no common system, the password manager is therefore often not a viable route.

#One-time links

This is where the one-time link comes in. Instead of sending the password itself, you deposit it with a service that generates a link which can be retrieved exactly once. You send that link by email. On first access the secret is displayed – and then deleted. A second access leads nowhere.

A useful property follows from this: if the recipient reaches an already-spent link, that is a warning sign. Either the secret has already been retrieved, or someone got there before them. The one-time link does not merely make a compromise less likely; it makes one visible. How this mechanism works in detail is covered more fully in One-Time Links: How They Work and When to Use Them.

#End-to-end encryption and zero-knowledge

A one-time link alone is not yet a complete answer. What matters is whether the provider of the service can read the deposited secret. Under a zero-knowledge approach this is ruled out: the password is encrypted in the sender's browser before it is transmitted. The key needed for decryption is part of the link – technically in the fragment after the hash symbol, which is never sent to the server in the first place. The service therefore stores only ciphertext it cannot read.

The practical consequence is far-reaching: even if the service provider were compromised, no password could be reconstructed from the stored data, because the key was never present there. What zero-knowledge means concretely, and where its limits lie, is explored in Zero-Knowledge Explained.

Crymbl combines these building blocks: a secret encrypted in the browser, a one-time link for handover and a self-destructing retrieval. The email then carries only the link – the password itself was never in plaintext in any mailbox.

#Avoid sending altogether where you can

The most secure handover is the one that never happens. Before considering the "how," it is worth asking whether a password needs to be sent at all:

• Invitation and registration flows: many systems let you create new users via an invitation link, where the recipient sets their own password. No password ever leaves the sender.
• Federated sign-in (SSO): where single sign-on is available, the separate password handover disappears entirely.
• Forced change on first login: if an initial password is unavoidable, it should be valid only briefly and mandatorily changed on first sign-in.

These measures move the secret out of transmission. What is never transmitted cannot be lost in transit.

#Sending passwords in a GDPR-compliant way

How a password is handed over is not only a technical question but a data protection one. Credentials almost always protect access to personal data; sometimes they are themselves personal data. Their protection therefore falls directly within the scope of the GDPR.

The governing provision is Article 32 GDPR, which requires appropriate technical and organisational measures for the processing of personal data, proportionate to the risk at hand – expressly including encryption where appropriate. Scattering a plaintext password across multiple mailboxes and backups is hard to justify as an appropriate measure against that standard. There is also the accountability principle: controllers must not only act appropriately but be able to demonstrate that they have done so.

For international organisations, the same logic holds: data minimisation argues against multiplying copies of a secret, and the accountability principle argues for a documented, defensible process. Methods built on transience and zero-knowledge map directly onto these requirements: confidential transmission, limited validity, no superfluous copies. The broader framing is covered in GDPR-Compliant Information Exchange.

#Checklist: handing over credentials securely

• Check whether sending a password can be avoided (invitation link, SSO, forced change).
• Never send the login name and the password over the same channel.
• No plaintext password in email, Slack, Teams or other searchable histories.
• Use a one-time link with limited validity for the handover.
• Ensure a zero-knowledge method in which the service cannot read the content.
• Instruct recipients to treat an already-spent link as a warning sign.
• Keep initial passwords valid only briefly and force a change on first login.
• Document the process in a traceable way to satisfy accountability.

#Common mistakes

Even with good tools, typical mistakes occur. The most common is to mix the link with explanatory context – for example, "Here is the password for the admin account: [link]." This reveals what the secret belongs to even after the link has been spent. Keep the accompanying message brief and low in context.

A second mistake is an overlong validity period. A one-time link that remains retrievable for weeks undermines the principle of transience. Choose the shortest window the recipient can realistically meet. The third mistake is the tacit assumption that the recipient proceeds with equal care – for instance, that they will not simply copy the retrieved content back into an email. A short instruction on handling therefore belongs to the handover. Guarding against such patterns is the subject of Protection Against Accidental Disclosure.

#Frequently asked questions

Is it safe to send passwords by email? A plaintext password by email is not safe, because it remains persistently, redundantly and searchably across several mailboxes and backups. Sending becomes safe only when the email carries a one-time link instead of the password, behind which the secret is deposited in encrypted and transient form.

May I send passwords over Slack or Microsoft Teams? This is inadvisable. These tools store messages by default, keep them searchable and are subject to administrative access. A password in a channel or history remains visible until it is actively removed – if the retention policy permits that at all.

Is it enough to send the login and password over two different channels? Separation is a sensible improvement but addresses only part of the problem. The password sent over the second channel can still be written down or stored. Combined with a transient, encrypted method, separation realises its full value.

What is a one-time link? A one-time link points to a secret that can be retrieved exactly once. On first access the content is shown and then deleted; any further access leads nowhere. As a result, an already-spent link is an indication that the secret has been retrieved.

What does zero-knowledge mean in this context? Zero-knowledge means that the intermediating service cannot read the secret itself. Encryption happens before transmission, and the key remains in the link without being sent to the server. Even if the service were compromised, the content could not be reconstructed.

How do I send credentials in a GDPR-compliant way? Transmit them confidentially, limit their validity, avoid superfluous copies and document the process. Article 32 GDPR requires appropriate technical and organisational measures; transient, encrypted methods meet that standard far better than a plaintext send.

#Conclusion

"Sending passwords by email" need not contradict security – provided the email no longer carries the password but only a reference to it. The real risk never lies in the act of sending, but in the persistence of plaintext across many places of retention.

Bringing together separation, transience and zero-knowledge inverts that risk: the secret exists only as long as needed, is unreadable to the intermediating service, and makes unauthorised access visible. The convenient email remains – the vulnerability disappears.