TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

77 点作者 slavomirvojacek将近 4 年前

7 条评论

contravariant将近 4 年前
Edit: This information is apparently outdated, see discussion below.<p>&gt; # Why should I trust you with my secrets?<p>&gt; 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.<p>Those are all good, but ultimately don&#x27;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&#x27;s being sent to the server or not. As it is it&#x27;s <i>definitely</i> sent to the server, you&#x27;ll just have to trust them that they wont use it for anything nefarious
评论 #28117088 未加载
评论 #28117041 未加载
评论 #28117126 未加载
fishtoaster将近 4 年前
Man, I would love a self-hosted version of this. I&#x27;ve worked at a lot of tiny startups and it often goes like this:<p>1. Sam needs to send some sensitive credentials to Alex<p>2. Well, we know we shouldn&#x27;t use slack or email<p>3. We should probably use a shared password manager, but that&#x27;d be a much larger conversation with the whole dev team<p>4. There are a ton of options if I search &quot;share secrets securely,&quot; but I&#x27;d have to dig into a few to figure out if I trust A. that company and B. their security model<p>5. Fuck it, just share it on slack, delete the message later, and hope for the best. We&#x27;ll figure out a better solution &quot;next time.&quot;<p>I&#x27;d love something simple and self-hosted that I could throw onto heroku, or deploy as a ready-made container, that&#x27;d provide one-time-use urls like this. It&#x27;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&#x27;t have to solve the trust problem every time.
评论 #28119506 未加载
评论 #28125687 未加载
评论 #28120093 未加载
评论 #28120176 未加载
评论 #28119262 未加载
评论 #28120124 未加载
bndw将近 4 年前
If anyone is curious like I was, here&#x27;s a quick review of what the linked code does:<p>- Reads plaintext input from stdin<p>- Symmetrically encrypts the plaintext using a 32-byte [cryptographically] random generated key (AES-256 GCM)<p>- POSTs the ciphertext and expiry (default 24h) to <a href="https:&#x2F;&#x2F;api.ots.sniptt.com&#x2F;secrets" rel="nofollow">https:&#x2F;&#x2F;api.ots.sniptt.com&#x2F;secrets</a><p>- The server responds with a URL to view the secret via a response header<p>- Query string &quot;?ref=cli&amp;v=&lt;version&gt;&quot; are appended to the secret URL<p>- The decryption key is base64 encoded and appended to the secret URL as a Fragment, &quot;#&lt;key&gt;&quot;<p>- The secret URL is printed to stdout
评论 #28119519 未加载
redm将近 4 年前
The problem with these one-time URL&#x27;s is that most people share them in places where the &quot;one-time&quot; 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&#x27;s already been burned.<p>You can whitelist those parties, but it somewhat defeats the purpose of a secure one-time link.
评论 #28119892 未加载
评论 #28119931 未加载
评论 #28120284 未加载
slavomirvojacek将近 4 年前
Hi all, since we&#x27;ve had a bit of traction today I thought I&#x27;d ask whether there are any additional features you&#x27;d like to see added?<p>For example, some sort of &quot;self-serve&quot; UI where you could get an API key which would allow users&#x2F;teams have dedicated rate-limits and not use the default&#x2F;public limits? Or a self-hosted option where the API could be deployed to the company&#x27;s cloud of choice?<p>Or.. leave as is?<p>Please let us know! :)
评论 #28118589 未加载
评论 #28119632 未加载
postalrat将近 4 年前
I&#x27;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.
yewenjie将近 4 年前
I have been wondering recently - how secure are URLs? For example Telegram&#x27;s bot API is authenticated with a token which has to be included in the URL for any request.<p>What kind of failure modes are there regarding this?
评论 #28117592 未加载
评论 #28117317 未加载