10 ms·

Show HN: Ots – share a secret via one-time URL

contravariant 5y ago
Edit: This information is apparently outdated, see discussion below. > # 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
- slavomirvojacek 5y ago
  Hi, I am one of the core members at Sniptt - we recently made the decryption key part of the fragment precisely for the above reason. I believe the GIF in the README is outdated :) - the newer versions of the CLI ought to place the decryption key in the fragment, but please let me know if that's not the case! Thanks.
  - contravariant 5y ago
    Oh, nice to see you're on top of things. Looks like the online version does indeed include the decryption key separately in a fragment.
  - BiteCode_dev 5y ago
    Is there a rate limit ? Because the convenience the cli gives would make it really easy to create a FUSE driver for it and store abitrary files.
    - slavomirvojacek 5y ago
      Hi, yes we've got basic rate limits in place, as well as other protective measures as this is pretty much an open endpoint. Please let me know if you'd like to learn more about how we're protecting the API as this is indeed quite an interesting topic in itself. Thanks!
      - BiteCode_dev 5y ago
        Great. Are you considering removing your call to google fonts ? It gives way too much data to google for something that is privacy oriented. Also, do you have a grace period for your burn after reading URL so that it can safely be sent by chats and emails system that visit any link you post ?
        slavomirvojacek 5y ago
        Great question - we will likely be looking at G Fonts alternatives as we are planning to revamp the entire website over the coming weeks/months. As for "grace period", are you asking about URL/link previews and whether those have any effect on reading the secret? If so, the answer is no - the secret will only be read once the client-side JavaScript code is loaded and executed, only certain layout components are rendered server-side. But I may have misunderstood your question, in which case please do not hesitate to ask again :)
        BiteCode_dev 5y ago
        Well, if you receive the url using gmail, google will visit the link, and execute the JS code. If you don't have a grace period, your secret will be unreadable before the human as a chance to get to it. Just saying that because, while at 0bin we have a 1 day default expiration delay, users can chose burn after reading. But we had to add a small grace period to allow for user to check the URL, reload by listake, send vua gmail, etc. I thin ots burn after reading by default so it could affect you.
        5y ago
- BiteCode_dev 5y ago
  Yep, that's what we do with https://0bin.net https://0bin.net. 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 :)
  - contravariant 5y ago
    Yeah guess you'd have to write your own client if you really wanted to be sure nobody could read the message in transit. But not sending the password to the server should at least remove the obvious 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).
    - BiteCode_dev 5y ago
      Yes, I think if they remove the cdn call it will start to be quite nice
  - giancarlostoro 5y ago
    The alternative is to do file transfers through WebRTC which is supposed to be end-to-end from my understanding.
    - BiteCode_dev 5y ago
      If you use a webclient, it doesn't matter, you trust the server no matter what you use. Ots cli has the advantage of being auditable once, and remain on your computer.
- zie 5y ago
  This is what firefox send did. The code is still maintained here: https://github.com/timvisee/send https://github.com/timvisee/send
yewenjie 5y ago
I have been wondering recently - how secure are URLs? For example Telegram's bot API is authenticated with a token which has to be included in the URL for any request. What kind of failure modes are there regarding this?
- jerf 5y ago
  If you use HTTPS, they're pretty much as secure as HTTPS itself is. Anything that would let you obtain or modify the token at that point would be a break of HTTPS. (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.
- itake 5y ago
  If they click on the URL while their internet is out, then the URL may remain in their browser's search history. The search history may sync between the devices, so if someone has access to your phone, they may get the secret URL when your internet resumes (and you haven't clicked yet). This probably isn't terrible though.
  - remram 5y ago
    In this case, the links are one-use, so if it's in your history it's already gone (and therefore secure).
slavomirvojacek 5y ago
Hi all, since we've had a bit of traction today I thought I'd ask whether there are any additional features you'd like to see added? 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! :)
- kodablah 5y ago
  > Or a self-hosted option where the API could be deployed to the company's cloud of choice? Can put it on Tor and give an ephemeral onion link (I wrote https://github.com/cretz/bine 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.
- bndw 5y ago
  Is the server component running at api.ots.sniptt.com open source? I looked through the org's repositories and wasn't able to find it.
  - slavomirvojacek 5y ago
    It is not at the moment but we are considering making the server + maybe infra repos public in the future, most likely when we've agreed on and implemented some sort of self-hosted option(s). 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.
redm 5y ago
The problem with these one-time URL's is that most people share them in places where the "one-time" is usually a cloud provider. If you share over IM, the IM service will check the URL to provide preview, or virus scan it. Same for many email providers. By the time you try to open it, it's already been burned. You can whitelist those parties, but it somewhat defeats the purpose of a secure one-time link.
- lixtra 5y ago
  The encrypted content should be served (and burned server-side) only to a POST request. No sane service can expect a POST request to be idempotent and therefore shouldn’t fire it (twice).
- bradknowles 5y ago
  That’s why I password protect any one-time URLs that I ever use, regardless of the provider. 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.
  - slavomirvojacek 5y ago
    We're considering adding additional password protection as a new feature (see https://github.com/sniptt-official/ots/issues/2 https://github.com/sniptt-official/ots/issues/2) - this password can then be shared via other channels with the recipient.
- slavomirvojacek 5y ago
  Hi, we will be using https://aws.amazon.com/waf/features/bot-control/ https://aws.amazon.com/waf/features/bot-control/ which should help somewhat, but I think we will have to spend a bit more time trying to establish a more robust solution.
fishtoaster 5y ago
Man, I would love a self-hosted version of this. I've worked at a lot of tiny startups and it often goes like this: 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.
- Pirate-of-SV 5y ago
  For the last couple of years my org has been self-hosting Yopass https://github.com/jhaals/yopass https://github.com/jhaals/yopass. We use it to share secrets (with one time URLs) with each other.
- slavomirvojacek 5y ago
  Hi, I am one of the co-creators of Sniptt. We faced this ourselves countless times, and it is exactly why we created both OTS and Snip (https://github.com/sniptt-official/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! :)
  - penagwin 5y ago
    Myself and I'm sure many other's can't wait to try it once you have the self hosted version!
- pimlottc 5y ago
bndw 5y ago
If anyone is curious like I was, here's a quick review of what the linked code does: - 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 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
- slavomirvojacek 5y ago
  Hi, just for completeness - the decryption key is added to the secret URL as a fragment in the penultimate step.
  - bndw 5y ago
    Thanks for the correction, updated.
postalrat 5y ago
I'm surprised nobody has created a sort of s3 service that only serves files once. It would be useful to enable services like this or other things like leaving a trail of files that reference future urls.

Edit: This information is apparently outdated, see discussion below. > # 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

slavomirvojacek 5y ago
Hi, I am one of the core members at Sniptt - we recently made the decryption key part of the fragment precisely for the above reason. I believe the GIF in the README is outdated :) - the newer versions of the CLI ought to place the decryption key in the fragment, but please let me know if that's not the case! Thanks.
- contravariant 5y ago
  Oh, nice to see you're on top of things. Looks like the online version does indeed include the decryption key separately in a fragment.
- BiteCode_dev 5y ago
  Is there a rate limit ? Because the convenience the cli gives would make it really easy to create a FUSE driver for it and store abitrary files.
  - slavomirvojacek 5y ago
    Hi, yes we've got basic rate limits in place, as well as other protective measures as this is pretty much an open endpoint. Please let me know if you'd like to learn more about how we're protecting the API as this is indeed quite an interesting topic in itself. Thanks!
    - BiteCode_dev 5y ago
      Great. Are you considering removing your call to google fonts ? It gives way too much data to google for something that is privacy oriented. Also, do you have a grace period for your burn after reading URL so that it can safely be sent by chats and emails system that visit any link you post ?
      - slavomirvojacek 5y ago
        Great question - we will likely be looking at G Fonts alternatives as we are planning to revamp the entire website over the coming weeks/months. As for "grace period", are you asking about URL/link previews and whether those have any effect on reading the secret? If so, the answer is no - the secret will only be read once the client-side JavaScript code is loaded and executed, only certain layout components are rendered server-side. But I may have misunderstood your question, in which case please do not hesitate to ask again :)
        BiteCode_dev 5y ago
        Well, if you receive the url using gmail, google will visit the link, and execute the JS code. If you don't have a grace period, your secret will be unreadable before the human as a chance to get to it. Just saying that because, while at 0bin we have a 1 day default expiration delay, users can chose burn after reading. But we had to add a small grace period to allow for user to check the URL, reload by listake, send vua gmail, etc. I thin ots burn after reading by default so it could affect you.
        5y ago
BiteCode_dev 5y ago
Yep, that's what we do with https://0bin.net https://0bin.net. 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 :)
- contravariant 5y ago
  Yeah guess you'd have to write your own client if you really wanted to be sure nobody could read the message in transit. But not sending the password to the server should at least remove the obvious 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).
  - BiteCode_dev 5y ago
    Yes, I think if they remove the cdn call it will start to be quite nice
- giancarlostoro 5y ago
  The alternative is to do file transfers through WebRTC which is supposed to be end-to-end from my understanding.
  - BiteCode_dev 5y ago
    If you use a webclient, it doesn't matter, you trust the server no matter what you use. Ots cli has the advantage of being auditable once, and remain on your computer.
zie 5y ago
This is what firefox send did. The code is still maintained here: https://github.com/timvisee/send https://github.com/timvisee/send

yewenjie 5y ago

I have been wondering recently - how secure are URLs? For example Telegram's bot API is authenticated with a token which has to be included in the URL for any request. What kind of failure modes are there regarding this?

jerf 5y ago
If you use HTTPS, they're pretty much as secure as HTTPS itself is. Anything that would let you obtain or modify the token at that point would be a break of HTTPS. (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.
itake 5y ago
If they click on the URL while their internet is out, then the URL may remain in their browser's search history. The search history may sync between the devices, so if someone has access to your phone, they may get the secret URL when your internet resumes (and you haven't clicked yet). This probably isn't terrible though.
- remram 5y ago
  In this case, the links are one-use, so if it's in your history it's already gone (and therefore secure).

slavomirvojacek 5y ago

Hi all, since we've had a bit of traction today I thought I'd ask whether there are any additional features you'd like to see added? 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! :)

kodablah 5y ago
> Or a self-hosted option where the API could be deployed to the company's cloud of choice? Can put it on Tor and give an ephemeral onion link (I wrote https://github.com/cretz/bine 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.
bndw 5y ago
Is the server component running at api.ots.sniptt.com open source? I looked through the org's repositories and wasn't able to find it.
- slavomirvojacek 5y ago
  It is not at the moment but we are considering making the server + maybe infra repos public in the future, most likely when we've agreed on and implemented some sort of self-hosted option(s). 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.

redm 5y ago

The problem with these one-time URL's is that most people share them in places where the "one-time" is usually a cloud provider. If you share over IM, the IM service will check the URL to provide preview, or virus scan it. Same for many email providers. By the time you try to open it, it's already been burned. You can whitelist those parties, but it somewhat defeats the purpose of a secure one-time link.

lixtra 5y ago
The encrypted content should be served (and burned server-side) only to a POST request. No sane service can expect a POST request to be idempotent and therefore shouldn’t fire it (twice).
bradknowles 5y ago
That’s why I password protect any one-time URLs that I ever use, regardless of the provider. 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.
- slavomirvojacek 5y ago
  We're considering adding additional password protection as a new feature (see https://github.com/sniptt-official/ots/issues/2 https://github.com/sniptt-official/ots/issues/2) - this password can then be shared via other channels with the recipient.
slavomirvojacek 5y ago
Hi, we will be using https://aws.amazon.com/waf/features/bot-control/ https://aws.amazon.com/waf/features/bot-control/ which should help somewhat, but I think we will have to spend a bit more time trying to establish a more robust solution.

fishtoaster 5y ago

Man, I would love a self-hosted version of this. I've worked at a lot of tiny startups and it often goes like this: 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.

Pirate-of-SV 5y ago
For the last couple of years my org has been self-hosting Yopass https://github.com/jhaals/yopass https://github.com/jhaals/yopass. We use it to share secrets (with one time URLs) with each other.
slavomirvojacek 5y ago
Hi, I am one of the co-creators of Sniptt. We faced this ourselves countless times, and it is exactly why we created both OTS and Snip (https://github.com/sniptt-official/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! :)
- penagwin 5y ago
  Myself and I'm sure many other's can't wait to try it once you have the self hosted version!
pimlottc 5y ago

bndw 5y ago

If anyone is curious like I was, here's a quick review of what the linked code does: - 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 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

slavomirvojacek 5y ago
Hi, just for completeness - the decryption key is added to the secret URL as a fragment in the penultimate step.
- bndw 5y ago
  Thanks for the correction, updated.

postalrat 5y ago

I'm surprised nobody has created a sort of s3 service that only serves files once. It would be useful to enable services like this or other things like leaving a trail of files that reference future urls.