How to Send a Password Securely?
Passwords should never be sent as plain text over email, chat applications, or SMS, as these channels create permanent records in server logs and backups. The safest approach is to generate a client-side encrypted, one-time link where the decryption key remains strictly within the URL fragment and never touches the host server. Transmit the resulting link and the corresponding username or extra password over two entirely separate communication channels.
- Standard email and enterprise chat platforms store messages indefinitely in searchable databases and backups.
- Sending both the username and password in the same message leaves zero defense if that channel is compromised.
- Secret Note performs client-side AES-GCM-256 encryption via WebCrypto before any payload leaves your browser.
- Under RFC 3986 section 3.5, web browsers never transmit URL fragment identifiers (#) to host servers.
- One-time secret links are permanently purged from the database immediately after the recipient retrieves them.
- Security best practices require recipients to rotate temporary credentials immediately after their initial login.
The Inherent Risks of Plain-Text Credential Sharing
In fast-paced working environments, copying and pasting passwords, API tokens, database connection strings, or temporary credentials into an email, Slack channel, or Microsoft Teams thread is commonplace. With email, TLS protects messages in transit only when both servers support it, but messages remain stored readable on the providers' servers and in every mailbox copy (and Gmail's 'confidential mode' restricts forwarding and downloading, but is not end-to-end encryption). Months or years later, a compromised email account can expose historic secrets via simple keyword searches.
Similarly, workplace chat platforms archive conversational history indefinitely on server infrastructure. Even in consumer messaging apps like WhatsApp where chats are end-to-end encrypted by default, 'view once' exists only for photos, videos, and voice messages (not text); disappearing messages can only be set to 24 hours, 7 days, or 90 days; chat backups are end-to-end encrypted only if the user explicitly turns that option on; and linked devices also receive messages. Consequently, permanent communication channels and default messaging tools are ill-suited for credentials.
Furthermore, desktop lock screens and push notifications can expose credentials to bystanders. Permanent, searchable communication channels were simply not designed for secure credential exchange.
The Out-of-Band Principle: Splitting Channels
A cornerstone of defense-in-depth security is the out-of-band principle. Compromising an account requires two fundamental pieces of information: an identifier (such as a username, email address, or server IP) and an authenticator (such as a password, private key, or PIN). Packaging both pieces into a single communication channel presents an adversary with a single point of failure.
When distributing credentials, split the delivery across two completely independent mediums. For instance, if you deliver the encrypted secret link via email, send the associated username or decryption passphrase via SMS, a Signal message, or a brief phone call. If an attacker intercepts the email, they obtain an encrypted payload or isolated credential without knowing where it belongs or how to decrypt it.
This split-channel hygiene is particularly critical when onboarding remote contractors, collaborating with third-party vendors, or provisioning infrastructure access across distributed teams.
Zero-Knowledge Encryption and One-Time Burn Links
The most effective mechanism for sharing ad-hoc secrets is a zero-knowledge, ephemeral link service. On Secret Note, encryption is executed directly within your browser using the native WebCrypto API. Your confidential string is encrypted locally with AES-GCM-256 using a randomly generated 256-bit symmetric key before any data is transmitted over the network.
When the encrypted ciphertext is saved to the server, the generated decryption key is placed exclusively in the URL fragment—the section following the hash sign (#). According to the internet standard RFC 3986 section 3.5, browsers never transmit fragment data to the host server in HTTP request headers. Consequently, the server stores only opaque, unreadable ciphertext. Server operators, hosting providers, or potential intruders have zero mathematical ability to decrypt the note.
When the recipient navigates to the link, their local browser extracts the decryption key from the URL hash, retrieves the ciphertext from the server, decrypts the message locally, and signals the server to permanently delete the ciphertext. Once burned, the note is completely erased from disk and cannot be accessed a second time.
Mitigating Link Crawler Bots and Accidental Leaks
Ephemeral links present two practical challenges: automated crawler bots and misdirected messages. Modern communication tools like Slack, Skype, and iMessage deploy automated unfurling crawlers that fetch web pages in the background to generate preview metadata. A naive one-time note tool that burns secrets on the initial HTTP GET request will inadvertently destroy the note before the human recipient even sees the message.
saklama.com eliminates this risk through a deliberate, two-stage retrieval flow. When a link is visited, the server only returns an introductory confirmation interface. The encrypted payload is not downloaded or burned until the human recipient explicitly clicks the View note button, completely immunizing the link against automated crawlers.
To guard against misdirected messages, senders can also configure an optional Extra password. This passphrase is processed using PBKDF2-SHA256 with 200,000 iterations. If an unauthorized recipient opens the link or an unauthorized party intercepts the message, they cannot view the secret without the passphrase. Crucially, entering an incorrect passphrase rejects the attempt in the browser without burning the server-side note, giving the rightful owner the chance to enter the correct code.
Post-Delivery Credential Hygiene and Rotation
A secure delivery pipeline is only part of credential governance. Any secret transmitted across external channels should be treated as fundamentally transitional. The sender should instruct the recipient to log into the target service and change the temporary password immediately upon receipt.
For permanent storage, recipients must avoid saving credentials in browser autofill notes, desktop scratch files, or inbox drafts. Instead, encourage the immediate transfer of credentials into a dedicated, audited password manager such as Bitwarden. By combining client-side browser encryption, split-channel distribution, one-time destruction, and immediate post-delivery rotation, your organization establishes a resilient defense against credential exposure.
- 1. Encrypt credentials locally in the browser: Visit not.saklama.com and type your secret. The data is encrypted on your device with AES-GCM-256 before transmission; plain text never touches the server.
- 2. Select expiration and burn conditions: Choose 'delete after reading' for one-time access, or set a defined lifespan between 1 hour and 30 days.
- 3. Configure an optional passphrase: Add a secondary password derived via PBKDF2 for layered protection. Incorrect attempts are rejected locally without burning the note.
- 4. Distribute link and metadata out-of-band: Share the generated link over your primary channel (e.g., email), while sending the associated username or extra passphrase via a second channel (e.g., SMS or Signal).
- 5. Confirm access and rotate the password: For one-time notes, verify that the recipient has decrypted the secret and consumed the link, then instruct them to reset the password immediately on the target platform.
Frequently Asked Questions
Why is sending passwords via Slack or Teams considered unsafe?
While communication is encrypted in transit, messages remain permanently saved in corporate chat databases, compliance archives, local application logs, and mobile notifications.
Can the server hosting Secret Note read my credentials?
No. All encryption is computed client-side using WebCrypto AES-GCM-256. The decryption key stays strictly inside the URL hash fragment, which browsers never transmit to web servers under RFC 3986 section 3.5.
Will link preview bots in messaging apps burn my one-time note?
No. When opened, not.saklama.com shows an advisory confirmation screen first. The encrypted payload is fetched and burned only when the user explicitly clicks 'View note'.
What happens if an eavesdropper accesses the link before the recipient?
For one-time notes, because the note self-destructs upon the first view, an unauthorized view consumes the secret. When the legitimate recipient opens the link, they will find it already deleted, alerting both parties to the breach.
Should organizations use password managers instead of one-time secret links?
Password managers are recommended for daily credential sharing among internal teams. However, one-time secret links provide the optimal zero-knowledge mechanism when sharing credentials with external clients or temporary contractors without vault accounts.