PassTransfer vs email: the difference in risk and convenience
Email is the default, and that is the problem
When someone needs to share a password quickly, email is the path of least resistance. Everyone has it, it requires no setup, and it works instantly. The problem is not that email fails to deliver the credential — it is that email succeeds too well. It delivers the credential and then keeps it, indefinitely, in multiple places at once.
What actually happens when you email a password
When you send a password via email:
- The password leaves your mail server in plain text (unless SMTP TLS is enforced end-to-end, which is not guaranteed)
- It is stored in your sent folder — permanently, unless you manually delete it
- It is stored in the recipient's inbox — permanently, unless they delete it
- It may be stored in your email provider's servers and backup systems
- If either party uses email archiving (common in corporate environments), it is in the archive
- It appears in any email security scanner logs
- If the email is replied to or forwarded, the credential propagates further
A credential sent by email is effectively public within any system that has ever touched that email, now and years into the future.
What happens when you share via PassTransfer
- You create a link containing the encrypted credential — this takes under a minute
- You send the link (via email, Slack, SMS — your choice)
- The recipient opens the link once and retrieves the credential
- The credential is deleted from the server immediately
- The link in the email/chat becomes a dead URL — no credential can be extracted from it
The only difference in workflow is creating the link. The delivery method (email, chat) can stay exactly the same.
Risk comparison
| Risk factor | PassTransfer link | |
|---|---|---|
| Credential persists in sender's sent folder | Yes — indefinitely | No |
| Credential persists in recipient's inbox | Yes — indefinitely | No |
| Credential in email archives | Yes | No |
| Credential accessible if email account is breached | Yes | No (already deleted) |
| Credential exposed if email is forwarded | Yes | No |
| Credential exposed if email is replied to | Yes | No |
| Multiple copies of credential exist | Yes | No |
Convenience comparison
| Aspect | PassTransfer link | |
|---|---|---|
| Requires recipient account | No | No |
| Extra steps for sender | No | 1 extra step (create link) |
| Works with existing email | Yes | Yes |
| Works across organizations | Yes | Yes |
| Recipient familiar with process | Yes | Learning curve — minimal |
The convenience argument is weak
The one extra step of creating a link before sending is the only meaningful convenience difference. It takes under 60 seconds. The security and compliance benefit is substantial. This is not a close trade-off.
The compliance argument is strong
Under GDPR, organizations are required to take appropriate technical measures to protect personal data. Passwords that grant access to systems containing personal data are within scope. Sending them via email, where they persist indefinitely in multiple locations, is difficult to defend as "appropriate technical measures." Using an encrypted one-time link that deletes the credential after delivery is a much stronger position.
Replace your email-based credential sharing with PassTransfer →
