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.
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).
Hi! I am Ruud, an engineer at Doppler. Good question! We made sure that the passwords in the URL are always stripped out when sending anything to Bugsnag. This way, we (or Bugsnag) never have enough information to decrypt the encrypted secrets.
However you make a good point, we initially added this to make sure the website is stable without errors, but at this point we can remove it (in progress at the moment).
My main concern with this or saltify.io is that when viewing network tab traffic in the browser, you can see the secret and the password are being sent back to their server. While we trust that our data are stored in encrypted form and the password+secret is only used in memory of serverside code to decrypt/encrypt, I would much prefer all of those operations being all done in the browser.
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.
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?
This is great feedback! I have updated the docs to show a placeholder token.
You are correct, the main Doppler product is not end-to-end encrypted. We use tokenization instead to secure the data. Here's a link that goes more in-depth on how that works: https://docs.doppler.com/docs/security-fact-sheet
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.
> 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
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 sharing! I have sent this feedback to our team as I am sure they will find it helpful. Separately, we do have an open Sr. AppSec role that you look like a great fit for. We love working with people that are direct who can also keep the conversation light hearted. If this sounds interesting, feel free to reach out directly at brian@doppler.com.
We move fast, don't have any brain teasers, and a care deeply about the culture we create.
Author of privapps Notebook, I just had first release couple of days ago. It was my side project and I didn't expect to monetize it, the notebook project is more like a missionary project.
I think e2e encryption and share is not new, especially compare to the privatebin, which has been out there for quite a long time, and it is mature with a lot of features, such as docker / K8s deployment.
If Droppler want to success, it might need to do slack integration, SSO and customize work. Since the space is very crowd there.
In addition, it can be very easy to be used for other purposes.
Edit: I read your site again, it is like try to make e2e encryption as a SaaS platform, for fast app development. This direction is kind of overlapping with vault:
https://spring.io/projects/spring-vault
Many cloud platform like AMZ, GCP have secrets management services, it can be a hard battle.
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!
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).
OSS which you host internally.
[1] https://plic.ml
[2] https://github.com/mohd-akram/plic
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?
You are correct, the main Doppler product is not end-to-end encrypted. We use tokenization instead to secure the data. Here's a link that goes more in-depth on how that works: https://docs.doppler.com/docs/security-fact-sheet
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.
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!
We move fast, don't have any brain teasers, and a care deeply about the culture we create.
Role: https://jobs.lever.co/doppler/63e3511b-5463-4d02-a1f9-0bc463...
and this one has much advanced features like build up a site. https://github.com/privapps/
All end to end encrypted.
https://news.ycombinator.com/item?id=26289683
I think e2e encryption and share is not new, especially compare to the privatebin, which has been out there for quite a long time, and it is mature with a lot of features, such as docker / K8s deployment.
If Droppler want to success, it might need to do slack integration, SSO and customize work. Since the space is very crowd there.
In addition, it can be very easy to be used for other purposes.
Edit: I read your site again, it is like try to make e2e encryption as a SaaS platform, for fast app development. This direction is kind of overlapping with vault: https://spring.io/projects/spring-vault
Many cloud platform like AMZ, GCP have secrets management services, it can be a hard battle.