Show HN: Temp.pw
temp.pw
temp.pw
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.
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)...
So your security posture with respect to this service is significantly different from people on the web.
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.
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.
- 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 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.)
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.
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.
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.
only "https://temp.pw/?item=82282c4798d60cb4"
https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
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.
its like a vault secret without the authn friction.