[HN Gopher] Show HN: Doppler Share - Share one-off secrets with ...
___________________________________________________________________
Show HN: Doppler Share - Share one-off secrets with end-to-end
encryption
Author : bvallelunga
Score : 52 points
Date : 2021-02-26 08:01 UTC (15 hours ago)
(HTM) web link (share.doppler.com)
(TXT) w3m dump (share.doppler.com)
| ppierald wrote:
| Similar to https://onetimesecret.com
|
| OSS which you host internally.
| ebfe1 wrote:
| 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).
| rgmvisser wrote:
| 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).
| bvallelunga wrote:
| 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!
| lotharrr wrote:
| 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!
| StavrosK wrote:
| 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.
| bvallelunga wrote:
| Thanks for reporting! We have a fix coming out in the next
| hour.
| bvallelunga wrote:
| We think we shipped the fix. Is the issue still occurring for
| you?
| baal80spam wrote:
| Exactly same configuration here and exact same result.
| serkanh wrote:
| Looks very similar to https://github.com/pinterest/snappass
| LittlePeter wrote:
| 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?
| bvallelunga wrote:
| 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.
___________________________________________________________________
(page generated 2021-02-26 23:01 UTC)