Show HN: Doppler Share – Share one-off secrets with end-to-end encryption (opens in new tab)

Brian from Doppler here. We are an easy way to manage environment variables across projects and services. We did a Launch HN last year: https://news.ycombinator.com/item?id=24719722. Since then, we've been hearing repeatedly from our users that they want a more secure way to share one-off secrets, like API keys, passwords, credit cards, coupons, wire info, lockbox codes, etc. This is understandable, since using Slack, SMS, or email for this leads to your secrets living unencrypted in those systems forever.

So we've made a new product to address this. It is a one-click way to share one-off secrets, end-to-end encrypted with links that auto-expire after a certain number of views and days.

All the encryption is done browser-side so our servers never see the raw secret or the encryption key. We use AES-GCM to encrypt your secrets, with a symmetric key derived from a cryptographically random 64 character passphrase using PBKDF2. If you want to dive deeper into how the data flows, we documented every step of the send and receive flows: https://docs.doppler.com/docs/share-security

We built this so anyone can use it immediately without needing to create an account or jump through any hoops.

Try it out: https://share.doppler.com/s/zg5aqzfbidn9femgnaas2wf2syedqf0s...

Would love to hear what you guys think!

Cool app! Doppler looks great but i have a tiny concern about the Bugsnag 3rd party script. Unless Doppler own Bugsnag, i think for a sensitive tool like secret sharing, you should remove it.

Shameless plug: I made a similar tool base off another project after FirefoxSend shuts down but deploy on AWS instead of GCP :) It is hosted here if anyone wanna take a look or roll their own https://www.relaysecret.com/. The design philosophy is the same (everything is encrypted on clientside, no plaintext or password leave clients browser, minimal backend).

Similar to https://onetimesecret.com

OSS which you host internally.

I made a similar service [1] for sharing one-off secrets. The implementation is open-source [2] and the client consists of a single HTML page (about 250 lines) with no external links or resources which makes it easy to review. Nothing is sent to the server except the encrypted blob.

[1] https://plic.ml

[2] https://github.com/mohd-akram/plic

I am browsing docs at https://docs.doppler.com and I noticed that in all your examples you do not authenticate even though this is needed when interacting with doppler. In most examples the required authentication is not even one extra line of code. Why would you leave that out?

I have an OCD where I want the examples to be complete, sorry for that. Otherwise the service looks interesting.

It seems that the main doppler product is not end-to-end encrypted, is that correct?

Looks very similar to https://github.com/pinterest/snappass

This is what I see when I try to share a link:

https://imgz.org/i3EfPoDo.png

I'm using Firefox with uBlock Origin, it might be hiding your field based on its ID if it's called "share" or something. I was very confused.

Curious to know if anyone uses Doppler or Doppler Share for personal use (sorta like a password manager with sharing features, which are usually not present in some password managers or are crudely implemented with other methods outside that application), and if yes, how it compares.

Based on inbound interest we launched an API where your apps can create Doppler Share links: https://docs.doppler.com/reference#share-secret

Hey.. neat project!

From the docs at https://docs.doppler.com/docs/share-security :

> 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. > .. > 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.

Using PBKDF (or any other "key-stretching" algorithm) is appropriate to prevent someone from cheaply building a table that maps from potential passphrase (+salt) to the potential symmetric key, ahead of time, and then quickly testing lots of potential keys against the encrypted data. If the passphrase is not full-strength to begin with, this is an important step.

But.. if you then send a non-stretched, simple hash of the passphrase to the server, you're giving up all that benefit. The server, anyone who breaks into it, or someone who can snoop on the conversation, gets to perform the fast pre-computed dictionary attack against the passphrase. You've prevented the ciphertext from being used as a cheap oracle, but allowed the server's hashed-passphrase to serve that role instead.

The document didn't say what character set was used for each of the 64 characters of the passphrase, but even if it's just hex, that still gives you a 256-bit key, which is effectively infinite. So in this case, I don't think you need the PBKDF.

If the passphrase were not that strong, then I'd recommend protecting both values against being used as an oracle:

1: run the passphrase through PBKDF (or Argon2, or bcrypt, whatever) to produce the "stretched passphrase" 2: hash the stretched passphrase one way to produce the encryption key, e.g. key = sha256("key:" + stretchedPassphrase) 3: hash the stretched passphrase a different way to produce the hash that you reveal to the server, hash = sha256("hash:" + stretchedPassphrase) 4: never reveal stretchedPassphase to anyone else, or use it directly for any other purpose

That way a dictionary attack against any of the revealed values are equally difficult. This is effectively the scheme we used on Firefox Accounts to protect the Sync password: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc... .

Also note: don't use different PBKDF round counts as a distinguisher, i.e. hash = PBKDF(rounds=10000, passphrase) and key = PBKDF(rounds=10001, passphrase). That amounts to the same thing, someone who learns the hash will get a cheap attack against the passphrase.

thanks for building this!

similar as https://github.com/PrivateBin/PrivateBin

and this one has much advanced features like build up a site. https://github.com/privapps/

All end to end encrypted.