This is so, utterly, unspeakably, NOT a good idea to use.
You're trusting a third-party server with the plaintext of an actual secret. This violates nearly every principle of good modern security.
If the author had somehow built and documented (and proved) a true zero-trust model that enables this kind of interaction, then that might be cool. But that is not this. For all we know, the author (or an insider threat working at AWS) is collecting these passwords into a database for crackers to try first before proceeding to cracking password hashes.
There are so many other ways to do this. E2E encrypted messaging with disappearing messages (Signal) is the bare minimum. Keybase messages (also E2EE) are also a semi-decent option. 1Password password sharing is a decent usability step up from those. For all three of these options, barring a compromise of the (carefully guarded) process for shipping frontend code to users, the security design guarantees no visibility to a third party, and they have white papers that go into great depth to explain why.
I disagree with this take because of the way people share passwords OOB right now meets zero security criteria.
- signal requires both users have signal and those personal contacts, as many regulated businesses can't use signal.
- Keybase isn't something people whose world is spreadsheets and slide decks encounter.
- 1Password requires an app or extension install.
Commercial options are so not economical that the OP went and built something.
I've worked on authenticator products, some which were standards candidates, along with a lot of identity and security architecture, and at limited scales, there is no risk in a third party generating the secret you're going to use for something that said party has no way to find.
Honestly, a lot of security concern reduces to bullshit, and for a limited set of use cases, like sending a password protected zip file between organizations, this online tool is pretty good. I commented elsewhere on the thread about some conditions, but really, this tool is just what most people need.
friction from cumbersome security workflows that people avoid creates more risk than using useful tools with some risk in them. pathological risk aversion is not security value either.
I'd like you to walk someone whose job isn't tech through generating a keypair, explaining to their counter party how to do the same, and they're going to exchange the secret using GPG for a zip file they are emailing. In 99% of cases it's stupid and discredits security as a field to raise histrionic criticisms and concerns.
Some secrets are more secret than others, and for low sensitivity tokens like temporary passwords, the risk/reward on this solution disqualifies the objections in your comment.
I was commenting more on "here's your password for this or that service", or a manual password reset process -- anything that would go into a table of hashes for an online service.
Risk I see is that this service is a target for folks who want to add some "known passwords" to their set. (Or maybe it's a honeypot for them, on account of how obvious of a target it is.)
Is a disappearing message on Signal protected from screenshots? Otherwise I think a disappearing message security is actually lower than a non-disappearing one because of the people that would screenshot it (I know I would w/o any hesitation; I hate data that disappears).
They require both parties to seek the vanishing as a useful feature (say, when you chat on someone and want to minimize the chance of being caught. There are certainly better examples).
If one of the parties did not want the message to dissapear it is here over: tout can take a picture and all security in the world won't prevent this.
Sorry, nothing personal. :) No shaming/accusation intended - all I intended was a warning to potentially naive readers about the security principles involved. Keep building, the UX is great.
Unfortunately, security stuff has some pretty hard lines we had to start drawing and moving further forward due to excellent security research (of whatever color hat)...
thanks. I think security is super important, however I do not think it is necessary to obsess over it for no reason. If I want to share a dev password with someone, I can tell them the login over discord and then send them a link to temp.pw. Easy peasy and absolutely no security risk. This is why I created it.
Why is the Share button greyed out, but clickable?
Did you vibe code this? (Those are two distinct questions, but yes, I was low-balling the effort that went into this web app.)
I don't know why the share button became that color. I actually made this years ago because I needed it for my company. But then file.io was acquired (which I was using for the backend), and so I had to recently switch to using aws as the backend. So I vibe-coded a new backend api for aws in the last couple of months. I also acquired the domain temp.pw - previously used temporary.pw (which still works).
A fun side project I guess, but I would never trust this for anything. Why would I use this instead of an actual password manager that has password sharing functionality? That also would not save a pw in chat history and has the added benefits on real security and not being some random site.
The "share which expires after one use" part requires the password either be visible to the server or encoded in the URL (also visible to to the server) unless you also want to share a password/key to access the password or, in which case the site doesn't make sense, or you want to require both folks are online at the same time to make a brokered WebRTC connection and share via that channel.
I think the intent is you have some crap messaging platform like email or SMS without and want to send a one time access link to the password. I'm not really sure how large the intersection of people who care enough about security to want that but not enough to want to avoid a 3rd party server and hoping first access of the link contents is by the intended target is though.
The server store encrypted password identified by item id. Browser side decrypt the encrypted password using key in the hash part. The hash part does not reach the server.
The full URL gets sent to the server on connection. You could break this out from the link, at which point you're back to sharing a password to share a password.
It has to, how would it deliver the password to the URL’s recipient otherwise?
I suppose to keep it fully stateless you could encode the password in the URL itself somehow, but then that would defeat the purpose of not having the secret hang around in perpetuity.
solves a common problem. assuming there's a real crng generating them, the links expire in a short window, they aren't logged, and the hashes aren't computed for a commercial rainbow table, what are the specific security objections to this?
its like a vault secret without the authn friction.
How would I connect it with any username or login? I just made it because I wanted something like this and make it available to others in case they find it useful. It is free and no ads
If you were a cracker, you'd add every one of these passwords to a database (maybe of up to 10B passwords) to try first before moving to cracking hashes.
You're trusting a third-party server with the plaintext of an actual secret. This violates nearly every principle of good modern security.
If the author had somehow built and documented (and proved) a true zero-trust model that enables this kind of interaction, then that might be cool. But that is not this. For all we know, the author (or an insider threat working at AWS) is collecting these passwords into a database for crackers to try first before proceeding to cracking password hashes.
There are so many other ways to do this. E2E encrypted messaging with disappearing messages (Signal) is the bare minimum. Keybase messages (also E2EE) are also a semi-decent option. 1Password password sharing is a decent usability step up from those. For all three of these options, barring a compromise of the (carefully guarded) process for shipping frontend code to users, the security design guarantees no visibility to a third party, and they have white papers that go into great depth to explain why.