A developer sends an API key through a workplace chat tool. Hours later, the cloud infrastructure is compromised. This scenario happens regularly and often stems from insecure credential sharing practices.
Compromised credentials are involved in the majority of data breaches. Many people share passwords via email, text, or messaging apps - methods that leave permanent trails. Understanding the security tradeoffs of different sharing methods helps you choose the right approach for each situation.
Why You Should Never Send Passwords by Email or Text
Email is not encrypted end-to-end. Every message you send sits in plaintext on mail servers, accessible to administrators, hackers, or anyone who compromises your account. Email providers keep messages indefinitely in backups.
Text messages aren't much better. They appear on lock screens, exist in cloud backups, can be read by your cellular provider, and persist in phone storage even after deletion. Both create permanent records that become security liabilities.
Here's what happens: You email a password to a colleague. Two years later, attackers breach your company's email server. They now have access to every password ever sent - including ones still in use. This scenario plays out thousands of times every year.
**Key statistics:** - Credential theft is involved in most data breaches - Email accounts are frequently compromised - Stolen credentials are traded on underground markets - Breaches often go undetected for extended periods
Once credentials are exposed, they can be exploited indefinitely.
7 Methods for Sharing Passwords
### Method 1: Self-Destructing Secret Links
**What it is:** Encrypted links that automatically self-destruct after one view. Various services (such as OneTimeSecret, PrivNote, or NovelCrypt) encrypt your password client-side and generate a unique URL that becomes invalid after viewing.
**How it works:** 1. Visit a self-destructing secret service 2. Enter your password in the form 3. Optionally add password protection and expiration 4. Copy the generated encrypted link 5. Share the link via your preferred channel (email, chat, text) 6. Recipient opens link - password is revealed and then deleted
**Pros:** - Minimal persistent storage - reduced long-term exposure - Works across any communication channel - No software installation required - Suitable for one-time credential sharing - Client-side encryption (when implemented properly)
**Cons:** - Single use only (can't retrieve if link is lost) - Requires internet connection for both parties - Security depends on the service provider's implementation
**Best for:** - Sharing passwords with contractors or vendors - Sending API keys to developers - Temporary access credentials - Database passwords for new team members - Situations where credentials shouldn't persist
**Note:** Multiple services offer this functionality with varying security implementations.
### Method 2: Password Managers with Sharing Features
**What it is:** Enterprise password managers like Bitwarden, 1Password, or LastPass include secure sharing features. Passwords stay encrypted in a vault and can be shared with specific users with granular permissions.
**How it works:** - Both sender and recipient need accounts with the same password manager - Sender shares password from their vault - Recipient gets access with optional view-only or edit permissions - Access can be revoked at any time
**Pros:** - Strong encryption (typically AES-256) - Fine-grained access controls - Audit trails show who accessed what and when - Passwords can be updated centrally - Suitable for ongoing team access
**Cons:** - Both parties need accounts (often paid) - Overkill for one-time sharing - Setup friction for external collaborators - Subscription costs for business features
**Best for:** - Sharing with team members - Ongoing access needs - Organization-wide password management - Situations requiring audit logs
### Method 3: End-to-End Encrypted Messaging Apps
**What it is:** Messaging apps with true end-to-end encryption like Signal, WhatsApp (regular chats), or Telegram (secret chats). Messages are encrypted in transit and only readable by sender and recipient.
**How it works:** - Send password via encrypted message app - Recipient reads it - Both parties manually delete the conversation
**Pros:** - End-to-end encryption protects in transit - Most people already have these apps installed - Free and convenient - No additional software needed
**Cons:** - Messages can be screenshot or copied - Requires manual deletion (easy to forget) - Still exists in chat history until manually cleared - Recipient's device stores plaintext password - Backups may not be encrypted
**Best for:** - Quick sharing with trusted individuals - Personal use between friends/family - When self-destruct isn't critical - Informal situations
### Method 4: Secure File Sharing with Encryption
**What it is:** Encrypt passwords in a file and share via secure platforms. Services like Tresorit, Proton Drive, or NordLocker provide encrypted cloud storage with granular access controls.
**How it works:** 1. Create text file containing passwords 2. Encrypt the file (using built-in encryption or tools like 7-Zip with AES-256) 3. Upload to secure file-sharing platform 4. Share access link with recipient 5. Recipient downloads and decrypts file
**Pros:** - File-level encryption adds protection layer - Can include multiple passwords at once - Access controls limit who can download - Audit logs available - Good for batch sharing
**Cons:** - More complex workflow than other methods - Requires accounts on both sides - Files persist unless manually deleted - Higher friction for quick shares
**Best for:** - Sharing multiple credentials simultaneously - Long-term secure storage with controlled access - Complex organizational requirements - Situations needing detailed audit trails
### Method 5: Split the Password (Two-Channel Method)
**What it is:** Divide the password into two parts and send each half through different communication channels. An attacker would need to compromise both channels to get the complete password.
**How it works:** 1. Manually split password in half (e.g., "MyP@ssword123" becomes "MyP@ss" and "word123") 2. Send first half via email 3. Send second half via text message or phone call 4. Recipient combines them to reconstruct password
**Pros:** - Low-tech solution requiring no special tools - Increases difficulty for attackers - More secure than single channel - Works without internet (if using phone call)
**Cons:** - Still creates permanent records in both channels - Manual process prone to user error - Not truly encrypted - just obfuscated - Inconvenient for long/complex passwords - Doesn't scale well
**Best for:** - Emergency situations - When no other methods available - Very short-term sharing (change password immediately after) - Low-tech environments
### Method 6: Phone Call or In-Person
**What it is:** The old-school approach - verbally communicate passwords over phone or face-to-face.
**Pros:** - No digital trail whatsoever - Can't be hacked remotely - Simple and straightforward - Works without technology
**Cons:** - Can be overheard by others nearby - Phone calls could theoretically be intercepted - Easy to mishear characters (is that "B" or "V"?) - Not scalable or convenient - Recipient still needs to enter it (opportunity for keyloggers)
**Best for:** - High-security environments - Short, simple passwords - When digital channels are compromised - Users uncomfortable with technology
### Method 7: QR Code (For Physical Sharing)
**What it is:** Encode passwords in QR codes for physical or screen-to-screen transfer. Recipient scans code with phone camera to instantly capture password without typing.
**How it works:** 1. Generate encrypted QR code containing password 2. Display on your screen or print it 3. Recipient scans QR code with phone 4. Password revealed and QR code deleted/destroyed
**Pros:** - No typing errors - perfect accuracy - Fast transfer when physically present - Can work offline - Good for complex passwords
**Cons:** - Requires physical proximity or screen sharing - Anyone with camera access can scan - QR code is effectively plaintext unless encrypted - Must securely delete/destroy QR code after use
**Best for:** - In-person meetings - Conference room Wi-Fi passwords - Physical location access codes - When both parties are in same room
**Note:** Some services offer QR code generation for encrypted messages, combining convenience with encryption.
Decision Matrix: Which Password Sharing Method is Right?
| Your Situation | Recommended Method | Why | |----------------|-------------------|-----| | One-time sharing with anyone | Self-destructing link | Zero persistence, works everywhere | | Ongoing team access | Password manager | Access control, auditing, central updates | | Emergency/quick share | Encrypted messaging app | Fast, end-to-end encrypted, convenient | | Multiple credentials at once | Secure file sharing | Batch handling, organized | | High-security environment | In-person + self-destruct link | Maximum security for critical secrets | | Sharing with non-technical person | Self-destructing link | No setup, no apps, just click link | | API keys or developer tokens | Self-destructing link | Designed for developer secrets | | Long-term team collaboration | Password manager | Ongoing access with revocation |
7 Password Sharing Mistakes That Put You at Risk
### 1. Sending passwords in the same message as username/URL
**Why it's bad:** If attackers intercept one message, they have everything needed to access the account.
**Better approach:** Send username/URL through one channel and password through a self-destructing link in another channel.
### 2. Reusing the same password across multiple accounts
**Why it's bad:** One breach exposes every account using that password. Credential stuffing attacks exploit this.
**Better approach:** Unique passwords for every account. Use a password manager to generate and store them.
### 3. Not setting expiration on shared passwords
**Why it's bad:** Passwords remain valid indefinitely, creating ongoing exposure risk.
**Better approach:** Set expiration times on shared secrets. Rotate passwords after temporary access ends. Use time-limited access tokens when possible.
### 4. Sharing passwords without context
**Why it's bad:** Recipient doesn't know what account it's for, leading to confusion and potentially pasting passwords in wrong places.
**Better approach:** Include non-sensitive context separately (e.g., "This is for the staging database" - but don't include the actual server address in the same message).
### 5. Not notifying when passwords change
**Why it's bad:** Collaborators still have old credentials, which may still work or may be exploited if leaked.
**Better approach:** Track who has access. When rotating passwords, notify everyone and reshare securely. Revoke old access immediately.
### 6. Using insecure "password generator" websites
**Why it's bad:** They may log generated passwords or inject subtle patterns. If the generator is compromised, so are your passwords.
**Better approach:** Use local password generators (built into password managers or operating systems) or trusted open-source tools.
### 7. Not deleting shared passwords after use
**Why it's bad:** Lingering credentials are security liabilities. The longer they exist, the more opportunities for compromise.
**Better approach:** Use self-destructing methods by default. For other methods, actively delete messages after recipient confirms receipt. Set calendar reminders to rotate passwords.
Your Secure Password Sharing Checklist
**Before sharing:** - ✓ Verify recipient's identity (phone call if high sensitivity) - ✓ Choose method appropriate for sensitivity level - ✓ Set expiration if available - ✓ Consider adding password protection layer - ✓ Never share password and username in same message
**During sharing:** - ✓ Use self-destructing link for one-time shares - ✓ Verify secure connection (HTTPS) - ✓ Confirm recipient received it - ✓ Don't email passwords (unless using encrypted email) - ✓ Use private/incognito window if on shared computer
**After sharing:** - ✓ Confirm successful access - ✓ Delete any local copies - ✓ Rotate password after temporary access ends - ✓ Remove access if using password manager - ✓ Document who has access (for audit purposes)
Real-World Scenarios: How to Share Passwords Securely
### Scenario 1: Sharing API Key with External Developer
**Problem:** You need to give a contractor access to your API for a 2-week project. The API key grants significant access to your production environment.
**Solution:** 1. Create self-destructing link containing API key 2. Set 7-day expiration as backup 3. Send link via email with instructions 4. Confirm contractor received and saved it 5. After project completion, immediately rotate API key 6. Issue new key if additional work is needed
**Why this works:** API key is not stored in permanent email. Self-destruct limits exposure. Even if the contractor's email is later compromised, the link is invalid. Rotation after project ends removes access.
**Tools:** OneTimeSecret, PrivNote, or similar services
### Scenario 2: New Employee Needs System Access
**Problem:** Onboarding new team member who needs passwords for 15 different internal systems.
**Solution:** 1. Use password manager's sharing feature (Bitwarden Teams, 1Password Business) 2. Create folder containing all necessary credentials 3. Share entire folder with new employee 4. Set up their personal password manager account 5. Have them change passwords to personal ones over first week 6. Revoke shared folder access after transition period
**Why this works:** Centralized management. Credentials never sent via email. Audit trail of access. Can revoke access instantly if needed. Employee builds their own secure vault.
**Tools:** Bitwarden Teams, 1Password Business, LastPass Business
### Scenario 3: Emergency Access During Incident
**Problem:** Production server down at 2 AM. On-call engineer needs root password immediately. Normal access systems are unavailable.
**Solution:** 1. Phone call to verify identity (callback to known number) 2. Create self-destructing link with root password 3. Send link via text message to verified number 4. Engineer accesses and resolves issue 5. Rotate root password first thing next morning 6. Document access in security log
**Why this works:** Phone verification confirms identity. Self-destruct limits exposure window. SMS works when other systems are down. Immediate rotation closes access window. Documentation maintains audit trail.
**Tools:** Phone verification + self-destructing link service + password rotation
Developer-Specific Password Sharing Tips
### For API Keys and Tokens
- **Never commit to Git** - Even private repos. Use .env files and add to .gitignore - **Use environment variables** - Keep secrets out of code - **Rotate after sharing** - Treat any shared key as potentially compromised - **Consider time-limited tokens** - Many APIs support temporary tokens instead of permanent keys
### For Database Credentials
- **Use self-destructing links** - One-time secure transfer - **Create temporary database users** - Grant limited access, revoke after project - **Rotate immediately after** - Change credentials after contractor/vendor access ends - **Use connection strings carefully** - They contain username, password, and host in one place
### For SSH Keys
- **Share public keys openly** - They're meant to be public - **NEVER share private keys** - If you must, encrypt first then use self-destruct link - **Use certificate-based auth** - Better than password-based authentication - **Consider SSH bastions** - Centralize access control
### Tools for Developers
**For quick credential sharing:** - OneTimeSecret - PrivNote - Similar self-destructing link services
**For production secrets management:** - HashiCorp Vault - AWS Secrets Manager - Azure Key Vault
**For team collaboration:** - Bitwarden - 1Password - LastPass
Improving Password Sharing Practices
Email and text messages create permanent records that can become security liabilities. Consider these approaches based on your needs:
**For one-time sharing:** Self-destructing link services provide a balance of convenience and reduced persistence. Multiple options exist with different implementations.
**For teams:** Password managers with sharing capabilities (such as Bitwarden, 1Password, or LastPass) enable centralized credential management with access controls.
**For developers:** Combining self-destruct links for ad-hoc sharing with proper secrets management systems (Vault, AWS Secrets Manager) addresses different use cases.
**General principle:** Evaluate the persistence and encryption of your chosen method against the sensitivity of the credential being shared.
Related Reading
Want to learn more about password security and digital privacy?
- Why Your Passwords Aren't As Safe As You Think - The Real Reason Your Private Messages Aren't Actually Private - How I Lost $3,000 to a Phishing Scam - Complete Guide to Secure Digital Communication