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.
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.
> low sensitivity tokens like temporary passwords
I 100% agree with you for that use case.
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).
Dissapearing messages have a limited use.
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.
yes truly awful, I should be ashamed for making it. Why do I make anything. Thank you for the feedback
I do not think this was personal. As a security professional I have the same reaction.
Security is hard, but not only in the technical area. The whole governance is not obvious for someone who did not have these threats on their radar.
If you do security you need to be ready to get feedback you do not expect, in areas you may have not fully addressed.
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.
Sounds like the temp.pw server is owned by you and you're willing to trust AWS with your secrets.
So your security posture with respect to this service is significantly different from people on the web.
Or you just tell them the password.
This is a much better way.
Yes, especially that you can use a "human-readable" password such as galleria-blunderer-tutor-omit-nursing-unify which is easy to provide via voice
... and as secure as ljpvxzbygjnzmbfoazibgmpwmegwkmrlczybzxgbctdbqkmtdq
This is pretty light on features and details.
When the use case comes up, I like to use https://github.com/pglombardo/PasswordPusher (online version here https://pwpush.com/). Which has generation, customizable # of visits, and a handful of other features.
yes I made it super simple on purpose, but pwpush looks cool!
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.
because it is about sharing a one-off password with someone so that you don't have to worry about it getting stored in chat history
Why does the "share" button upload the password to your server in plaintext?
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.
https://temp.pw/?item=82282c4798d60cb4#key=idh36ud
I think something like this could work.
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.
"#key=idh36ud" doesn't get sent to the server.
only "https://temp.pw/?item=82282c4798d60cb4"
https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
TIL!
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.
Encrypt password with a given key, send that to the server. Include the key in the `#fragment` of the URL to Share.
Oh I was just talking about the “transmitting to the server _at all_” part, but yeah some end-to-end encryption would be nice.
I just use my password manager.
https://support.1password.com/share-items/
This generates a random password that can be shared via a one-time link. Why? What is the situation where this would be used?
when you want to share a password with someone but don't want the password to remain in chat history
Nice try, Satan.
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.
Feedback: Input box gives zero clue that it is editable. Share button looks disabled button.
nice work. i've used https://onetimesecret.com/ for this kind of thing for several years
Honeypot?
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.
Honeypot.
openssl rand -base64 12