Show HN: Doppler Share – Share one-off secrets with end-to-end encryption(share.doppler.com)
share.doppler.com
Show HN: Doppler Share – Share one-off secrets with end-to-end encryption
https://share.doppler.com
22 comments
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).
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).
Similar to https://onetimesecret.com
OSS which you host internally.
OSS which you host internally.
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.
[1] https://plic.ml
[2] https://github.com/mohd-akram/plic
[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?
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
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
Please do not call that OCD
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.
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.
Thanks for reporting! We have a fix coming out in the next hour.
We think we shipped the fix. Is the issue still occurring for you?
It is not, thank you!
Exactly same configuration here and exact same result.
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!
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!
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 [email protected].
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...
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...
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.
and this one has much advanced features like build up a site. https://github.com/privapps/
All end to end encrypted.
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.
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.
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.
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!