3 ms·

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 eve

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.

ca98am79 2y ago
yes truly awful, I should be ashamed for making it. Why do I make anything. Thank you for the feedback
- TimTheTinker 2y ago
  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)...
  - ca98am79 2y ago
    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.
    - TimTheTinker 2y ago
      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.
    - BrandoElFollito 2y ago
      Or you just tell them the password.
      - TimTheTinker 2y ago
        This is a much better way.
        BrandoElFollito 2y ago
        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
        BrandoElFollito 2y ago
        ... and as secure as ljpvxzbygjnzmbfoazibgmpwmegwkmrlczybzxgbctdbqkmtdq
- BrandoElFollito 2y ago
  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.
frizlab 2y ago
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).
- BrandoElFollito 2y ago
  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.
motohagiography 2y ago
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.
- TimTheTinker 2y ago
  > 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.)

ca98am79 2y ago

yes truly awful, I should be ashamed for making it. Why do I make anything. Thank you for the feedback

TimTheTinker 2y ago
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)...
- ca98am79 2y ago
  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.
  - TimTheTinker 2y ago
    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.
  - BrandoElFollito 2y ago
    Or you just tell them the password.
    - TimTheTinker 2y ago
      This is a much better way.
      - BrandoElFollito 2y ago
        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
        BrandoElFollito 2y ago
        ... and as secure as ljpvxzbygjnzmbfoazibgmpwmegwkmrlczybzxgbctdbqkmtdq
BrandoElFollito 2y ago
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.

frizlab 2y ago

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).

BrandoElFollito 2y ago
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.

motohagiography 2y ago

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.

TimTheTinker 2y ago
> 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.)