> # Why should I trust you with my secrets?
> All secrets are encrypted end-to-end, which means the plaintext values never leave your device. We do not log, track, share, or store the encryption key that protects your secret. You can check the client code to learn more about how we create the encryption key as well as what data is being sent to our servers.
Those are all good, but ultimately don't really answer the question when the decryption key is part of the URL. If you wanted to avoid the necessity to trust secure.sniptt.com the decryption key should at least have been placed inside the fragment. Then you could at least verify if it's being sent to the server or not. As it is it's definitely sent to the server, you'll just have to trust them that they wont use it for anything nefarious
Also you must avoid client side 3rd party scrips, so no analytics. Also no cdn. I hope ots will self host their google fonts at some point, since you basically slink all secret URL to you google account (albeit without pwd) if you are logged in.
We also had several demands for an url shortener but couldn't find a sustainable way to do it. 3rs party have rate limits and hosting our own would get us back to step one.
DMCA also gets really interesting when you get a request but they don't include the hash because some of their tooling strip it along the way.
Anyway, even with all that, you still trust us since we could inject a rogue script at any time in the page.
So the process really protects only us as host (see our faq), but if you want real security, use pgp or signal. Or if you like the cmd thingy, magic wormhole is kinda awesome.
Still better than sending a password using plan text of course :)
And credit to the Sniptt team, apparently they do actually put the password in the fragment in newer versions (and presumably you could build your own client for it using this repository if you're extra paranoid).
1. Sam needs to send some sensitive credentials to Alex
2. Well, we know we shouldn't use slack or email
3. We should probably use a shared password manager, but that'd be a much larger conversation with the whole dev team
4. There are a ton of options if I search "share secrets securely," but I'd have to dig into a few to figure out if I trust A. that company and B. their security model
5. Fuck it, just share it on slack, delete the message later, and hope for the best. We'll figure out a better solution "next time."
I'd love something simple and self-hosted that I could throw onto heroku, or deploy as a ready-made container, that'd provide one-time-use urls like this. It'd be a great way to have slightly better secret delivery over insecure channels (like slack) in the early days of an eng team before we get around to setting up a unified system for secret sharing. And easy self-hosting means we don't have to solve the trust problem every time.
We faced this ourselves countless times, and it is exactly why we created both OTS and Snip (https://github.com/sniptt-official/snip - like OTS but with the ability to persist secrets and also create shared vaults etc.).
Pleased to say that self-hosted options for both OTS and Snip are currently top of our roadmap.
Keep an eye on the repos for updates! :)
Create a GPG key and encrypt / decrypt your messages.
It takes about 10 minutes once to set up your key and then it's easy to send and receive encrypted messages with no central server since you could send the encrypted text over whatever transport mechanism you prefer (gist, email, etc.).
- Reads plaintext input from stdin
- Symmetrically encrypts the plaintext using a 32-byte [cryptographically] random generated key (AES-256 GCM)
- POSTs the ciphertext and expiry (default 24h) to https://api.ots.sniptt.com/secrets
- The server responds with a URL to view the secret via a response header
- Query string "?ref=cli&v=<version>" are appended to the secret URL
- The decryption key is base64 encoded and appended to the secret URL as a Fragment, "#<key>"
- The secret URL is printed to stdout
You can whitelist those parties, but it somewhat defeats the purpose of a secure one-time link.
They can’t cause the URL to auto-expire if they don’t have the password.
This password on the one-time URL is something that I share via less secure methods and is easily guessable. It’s only purpose is to prevent the one-time URL from being auto-expired by malware checkers or preview creators.
For example, some sort of "self-serve" UI where you could get an API key which would allow users/teams have dedicated rate-limits and not use the default/public limits? Or a self-hosted option where the API could be deployed to the company's cloud of choice?
Or.. leave as is?
Please let us know! :)
Can put it on Tor and give an ephemeral onion link (I wrote https://github.com/cretz/bine to help w/ just these use cases). So people could access via Tor browser or via the same CLI with a "client"/"get" command. Can even have the ephemeral server determine its been HTTP "GET"d and kill itself. Then you don't even need a public website.
We will probably write a blog post or two about how we've designed the API + infra around it as there are some interesting topics to be covered.
One of the goals was to also have fun and experiment with a few approaches we've been wanting to use but could not on our daily jobs.
For reference, everything is on AWS and we are using AWS CDK (TypeScript), having moved away from serverless.com recently.
We are ONLY using managed services/resources which are "fully serverless" (API GW, WAF, Dynamo + Dynamo Streams, Lambda, EventBridge, ...) - to save cost, to minimise waste, to reduce ops, etc.
Hope this helps, happy to provide more details.
What kind of failure modes are there regarding this?
This probably isn't terrible though.
(Unless you're using some weird system where the secret is in the domain name, in which case it can be a bit more complicated, but who does that?)
If you use HTTP they're not secure at all.
