Doppler Share Security

This document provides an overview of Doppler Share's design and data flow. For information on TLS requirements, data access, and more, check out our general Security Fact Sheet.

Client-Side Zero-Trust Encryption

Doppler Share uses client-side encryption to ensure plain text secrets never touch our systems. We use AES-GCM to encrypt your secrets, with a symmetric key derived from a cryptographically random 64 character passphrase using PBKDF2.

Send Data Flow

1. User enters secret and clicks Submit.
2. Client-side JavaScript generates a cryptographically random 64 character passphrase
3. Client-side JavaScript generates a symmetric key using the passphrase, random salt, and 100,000 rounds of PBKDF2.
4. Client-side JavaScript encrypts secret using symmetric key and random IV
5. Client-side JavaScript create SHA256 hash of the passphrase
6. Client-side JavaScript sends the encrypted secret, hashed passphrase, and expiration details (days/views) to the server.
7. Server receives the POST request and saves a record to Doppler's database. The server responds with a link to to the shared secret.
8. Client-side JavaScript receives the link and appends the passphrase to it via the URL hash property.
9. The link is displayed to the user.

Receive Data Flow

1. User visits share page with previously-generated ID included in the URL.
2. Server verifies ID exists and hasn't expired. It then either renders the view page (if unexpired) or redirects to the Share homepage.
3. Client-side JavaScript checks for the passphrase in the hash property of the URL and prefills it into the passphrase input form, if specified.
4. User clicks Submit.
5. Client-side JavaScript create SHA256 hash of the passphrase.
6. Client-side JavaScript sends POST request to Doppler's server containing the id of the share link and the hashed passphrase.
7. Server receives the POST request and looks up the unexpired database row using the ID and hashed passphrase. If found, it responds with the encrypted secret. Otherwise, it throws an error.
8. Client-side JavaScript regenerates the symmetric key using the passphrase and 100,000 rounds of PBKDF2.
9. Client-side JavaScript decrypts the secret using the symmetric key.
10. The decrypted secret is shown to the user.

Slack App

Due to limitations with Slack, secrets shared through our Slack app will be encrypted on our servers. Unencrypted data is never stored in our systems.

Send Data Flow

1. User enters secret into Slack
2. Slack sends secret and expiration details (days/views) to the server.
3. Server generates a cryptographically random 64 character passphrase
4. Server generates a symmetric key using the passphrase, random salt, and 100,000 rounds of PBKDF2.
5. Server encrypts secret using symmetric key and random IV
6. Server create SHA256 hash of the passphrase
7. Server saves the encrypted secret, hashed password, and expiration details (days/views) to Doppler's database. The server responds with a link (including the hashed password) to the shared secret.
8. Slack receives the link
9. The link is displayed to the user.