[ttldr]

looks neat! would love to use something like this at work.

with regards to the S3 fail-over, how do you manage per-account access/authz?

source of fetch.go seems to indicate a single bucket is used for the fail-over: http://bit.ly/2p6ozyN

do you create per-account restricted policies and somehow have the client assume a particular IAM role or do you just have a world-readable bucket and rely on PGP for secrecy?

UPDATE: turns out that the first half of the ENVKEY (before the '-') is some sort of "env id". the S3 URL is then formed by appending the API version (v1 is valid, not sure if it's current) to the base bucket and prefix (see earlier bit.ly). for shits 'n giggles, let's try using the ENVKEY from the site's landing page ("p9WYzzHefy33gzgDdvPJ-EKdh4jgBsRBBNerK").

let's test it out with a simple, unauthenticated cURL:

  $ curl -s s3-eu-west-1.amazonaws.com/envkey-backup/envs/v1/p9WYzzHefy33gzgDdvPJ | wc -c
     15291

  $ curl s3-eu-west-1.amazonaws.com/envkey-backup/envs/v1/p9WYzzHefy33gzgDdvPJ
  ...

small sample of output for latter cmd: https://pastebin.com/igXQrk2z

so, it appears that the fail-over "feature" exposes your PGP-encrypted secrets to the world _without any authentication whatsoever_. PGP is pretty secure, and the space of potential IDs seems pretty large (20 chars^(26+26+10) ~ 4.61e80 potential IDs) so that's probably fine...

can users opt-out of the fail-over feature?

EDIT: s/security-by-obscurity//

[danenania]

Thanks for the feedback and for laying out your investigation :)

I'd say it's pretty unfair to call a 20 char id 'security-by-obscurity', unless you want to call almost every username/password authentication mechanism the same. The id has vastly more entropy than the average password and is far beyond brute-forcible.

Along the same lines, there are no known attacks that can break 2048 bit PGP with a sufficiently strong passphrase.

So there are two layers of security that cannot be broken by any real-world attacks. I believe that is indeed sufficient for protecting customer data.

It's likely that we'll move away from the S3 failover eventually in favor of our own replication strategy. This wouldn't really have security implications, but it does make it simpler to have a single source of truth for logging, which is coming soon.

[ttldr]

all fair points. and your product seems to be designed/documented/marketed with the notion of keeping the username (which is part of the ENVKEY) secret, so agreed that "security-by-obscurity" is unfair (coupled w/ massive ID space).

your product is very well designed, seems like a tremendous customer experience. best of luck; i hope you continue to grow