Overview

Core's Secure Password Sharing lets you send passwords and other sensitive content to clients and teammates with zero-knowledge encryption. Content is encrypted in your browser using AES-256-GCM before anything is sent to our servers. The password that decrypts the content is never transmitted to or stored by Core — we couldn't read your share even if compelled to.

How it works

Every share has two halves:

1. A link — a server-side lookup ID. Anyone with the link can fetch the encrypted blob, but the blob is unintelligible without the password.
2. A password — the only key material. Strong passwords are auto-generated for you. The recipient enters this password in their browser, which derives the key (PBKDF2-SHA256, 600,000 iterations) and decrypts the content locally.

Because the password never leaves the browser, neither Core nor a database administrator nor an attacker who breaches our backend can decrypt your content. The trade-off: if the password is lost, the share cannot be recovered.

Send the link and password through different channels

This is the most important rule. The link and the password are two halves of one secret. Anyone with both can decrypt the content. Send them through different channels:

• Link → email, Slack, ticket comment, or any normal channel
• Password → SMS, phone call, encrypted messenger, or in person

If both go in the same email or chat thread, the encryption can't protect you — anyone who reads that message has everything. The Core UI makes this obvious by presenting the link and password in two separate copy fields with a reminder banner.

Two sharing modes

Temporary

For one-time delivery to external users:

• Auto-deletion after expiration or after the view limit is reached
• View limits of 1–10
• Expiration from 1 hour to 30 days
• The encrypted content is fully erased once consumed

Use for: one-time customer password delivery, temporary contractor credentials, client WiFi passwords, short-lived API tokens.

Persistent

For internal team storage with resettable access for external users:

• Your team retains access to view the share through the admin panel
• Reset the expiration if a customer misses the window
• Reset the view count as needed
• Content remains available for your team indefinitely

Use for: team-wide admin password storage, customer infrastructure credentials, resettable client access links, long-term documentation.

Creating a share

1. Open Password Sharing from the main navigation
2. Click New Share
3. Enter the content
4. Choose share type, expiration, and view limit
5. A strong password is generated automatically — keep it, regenerate it, or replace it with your own (minimum 12 characters)
6. Click Create Share
7. The success dialog gives you two fields to copy: Link and Password. Send them via different channels.

Viewing a shared link

The recipient:

1. Opens the link
2. Enters the decryption key
3. Clicks Show content
4. The content is decrypted entirely in their browser

For temporary shares, a view is counted only after the browser decrypts the content successfully. A wrong key does not consume the share. If loading or access confirmation is interrupted, use Try again; Core keeps only a short-lived confirmation proof for recovery and never stores the decryption key or decrypted content. When views are exhausted or expiration is reached, the encrypted content is wiped.

Managing persistent shares

In the admin panel, anyone with the right permissions can:

• View the share's metadata (name, customer, contact, view count, expiration)
• Reset expiration to extend the access window
• Reset the view count
• Copy the link (useful for resending — the recipient still needs the password you sent originally)
• Delete the share

The admin panel cannot show or recover the original password: we never had it. If a recipient lost the password, you'll need to delete the share and create a new one.

Security model in one paragraph

Encryption happens in the browser using AES-256-GCM with a random 128-bit IV per share. The key is derived from the user-supplied password via PBKDF2-SHA256 with 600,000 iterations and a 256-bit random salt. The server stores ciphertext, IV, salt, and a one-way claim verifier — it never sees the password and cannot derive the encryption key. Every caller is rate-limited across application instances. After the browser decrypts successfully, it sends a domain-separated proof that lets the server atomically record and consume the access without exposing the key. Public URL lookups run only through the application gateway; the underlying full-row database functions are service-role-only.

Legacy shares

Shares created before the zero-knowledge cutover continue to work through their original URLs. They appear in the admin list with a Legacy badge. Their security model is the older one: the URL itself contains enough material to decrypt (with the password as an optional second factor for some). They will continue to function until they expire or are deleted; new shares always use the zero-knowledge model.

If a legacy share's contents are still needed long-term, recreate it as a new zero-knowledge share and delete the legacy one.

Best practices

• Always send link and password via different channels. This is the single most impactful thing you can do.
• Don't reuse passwords across shares. The auto-generator gives a fresh one each time — keep it.
• Use temporary mode by default. Persistent shares stay around indefinitely for your team; only choose persistent when you actually need the long-term access.
• Set short expirations. A 1-hour expiry is reasonable for most ad-hoc credential handoff.
• Tell recipients to copy the password directly from your SMS / call rather than retyping it. Reduces transcription errors with a 20-character random password.

See also

• Team Management
• Permissions & Roles

Overview

Core's Secure Password Sharing lets you send passwords and other sensitive content to clients and teammates with zero-knowledge encryption. Content is encrypted in your browser using AES-256-GCM before anything is sent to our servers. The password that decrypts the content is never transmitted to or stored by Core — we couldn't read your share even if compelled to.

How it works

Every share has two halves:

1. A link — a server-side lookup ID. Anyone with the link can fetch the encrypted blob, but the blob is unintelligible without the password.
2. A password — the only key material. Strong passwords are auto-generated for you. The recipient enters this password in their browser, which derives the key (PBKDF2-SHA256, 600,000 iterations) and decrypts the content locally.

Because the password never leaves the browser, neither Core nor a database administrator nor an attacker who breaches our backend can decrypt your content. The trade-off: if the password is lost, the share cannot be recovered.

Send the link and password through different channels

This is the most important rule. The link and the password are two halves of one secret. Anyone with both can decrypt the content. Send them through different channels:

• Link → email, Slack, ticket comment, or any normal channel
• Password → SMS, phone call, encrypted messenger, or in person

If both go in the same email or chat thread, the encryption can't protect you — anyone who reads that message has everything. The Core UI makes this obvious by presenting the link and password in two separate copy fields with a reminder banner.

Two sharing modes

Temporary

For one-time delivery to external users:

• Auto-deletion after expiration or after the view limit is reached
• View limits of 1–10
• Expiration from 1 hour to 30 days
• The encrypted content is fully erased once consumed

Use for: one-time customer password delivery, temporary contractor credentials, client WiFi passwords, short-lived API tokens.

Persistent

For internal team storage with resettable access for external users:

• Your team retains access to view the share through the admin panel
• Reset the expiration if a customer misses the window
• Reset the view count as needed
• Content remains available for your team indefinitely

Use for: team-wide admin password storage, customer infrastructure credentials, resettable client access links, long-term documentation.

Creating a share

1. Open Password Sharing from the main navigation
2. Click New Share
3. Enter the content
4. Choose share type, expiration, and view limit
5. A strong password is generated automatically — keep it, regenerate it, or replace it with your own (minimum 12 characters)
6. Click Create Share
7. The success dialog gives you two fields to copy: Link and Password. Send them via different channels.

Viewing a shared link

The recipient:

1. Opens the link
2. Enters the decryption key
3. Clicks Show content
4. The content is decrypted entirely in their browser

For temporary shares, a view is counted only after the browser decrypts the content successfully. A wrong key does not consume the share. If loading or access confirmation is interrupted, use Try again; Core keeps only a short-lived confirmation proof for recovery and never stores the decryption key or decrypted content. When views are exhausted or expiration is reached, the encrypted content is wiped.

Managing persistent shares

In the admin panel, anyone with the right permissions can:

• View the share's metadata (name, customer, contact, view count, expiration)
• Reset expiration to extend the access window
• Reset the view count
• Copy the link (useful for resending — the recipient still needs the password you sent originally)
• Delete the share

The admin panel cannot show or recover the original password: we never had it. If a recipient lost the password, you'll need to delete the share and create a new one.

Security model in one paragraph

Encryption happens in the browser using AES-256-GCM with a random 128-bit IV per share. The key is derived from the user-supplied password via PBKDF2-SHA256 with 600,000 iterations and a 256-bit random salt. The server stores ciphertext, IV, salt, and a one-way claim verifier — it never sees the password and cannot derive the encryption key. Every caller is rate-limited across application instances. After the browser decrypts successfully, it sends a domain-separated proof that lets the server atomically record and consume the access without exposing the key. Public URL lookups run only through the application gateway; the underlying full-row database functions are service-role-only.

Legacy shares

Shares created before the zero-knowledge cutover continue to work through their original URLs. They appear in the admin list with a Legacy badge. Their security model is the older one: the URL itself contains enough material to decrypt (with the password as an optional second factor for some). They will continue to function until they expire or are deleted; new shares always use the zero-knowledge model.

If a legacy share's contents are still needed long-term, recreate it as a new zero-knowledge share and delete the legacy one.

Best practices

• Always send link and password via different channels. This is the single most impactful thing you can do.
• Don't reuse passwords across shares. The auto-generator gives a fresh one each time — keep it.
• Use temporary mode by default. Persistent shares stay around indefinitely for your team; only choose persistent when you actually need the long-term access.
• Set short expirations. A 1-hour expiry is reasonable for most ad-hoc credential handoff.
• Tell recipients to copy the password directly from your SMS / call rather than retyping it. Reduces transcription errors with a 20-character random password.

See also

• Team Management
• Permissions & Roles