I made a service to share passwords easy and secure but never promoted it. It's called instapass.io I noticed that people besides my friends and clients actually started to use, so maybe it will be helpful for you too! You share one-time self-destruct message using one time links and I won't even be able to see what you wrote.
How does it work? When you generate a message the client-side makes a random password and use that to encrypt the message. The password is appended as an anchor tag which all modern browsers never send to the server. This way, I don't even know what you shared. Why this and not one of the fancy solutions that exist? Time and complexity. In my experience, people never get around to setup the services especially if you're a consultant like me. And then comes the part of trying to explain to a non-technical person how a master password is and how to share it and signup etc. Instapass offers high security, zero setup time and works for non-developers.
Martin.
Also, don't forget to let the recipient know to also read all of the javascript so that they can let you know if the plaintext was sent off to the provider the moment they open the link you sent them.
[0] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Either you are able to transmit the link via a secure channel, then you are able to transmit the message via this channel in the first place.
Logging might be something that can be circumvented with this service, but this instantly raises a second question: Why should users trust you versus any other service provider?
Please do not advertise this service as secure.
Yes, self-destructing messages are more secure than simply pasting plain text. But it's offering no protection against eavesdropping, so it's not secure.
Meaning you now have to find a way to safely send this URL ... and you are right where you started. It's no safety at all.
so, it doesn't solve every problem, but it does solve most real problems.
It encrypts a secret message by ... generating a random password and using symmetric encryption.
If only there was a way to safely pass the password that encrypts my password. Or should I recursively use this tool for the job?
1) The 500 character limit
2) If you enter someone's Gmail, and it's actually one of their aliases, then they can't decrypt the message when they sign in.
Pros: messages are deleted completely, messages are individually AES-256 encrypted, can only be decrypted with the generated link, the wehsite itself cannot read or decrypt messages, no ip logging, multiple languages, exists since 2014, PWA available
Cons: ads (but deactivatable)
That's not to say other websites like this are trustworthy (they aren't, JavaScript can change at any time), but this is blatantly non-trustworthy.
So how do you transmit those links securely and why didn't you use that for your passwords in the first place?
The main issues here are:
* You have to trust the client implementation to not surreptitiously record the one-time key (for both sender and receiver).
* You have to trust the site operator to actually expire the message after one use.
* Whatever secret you are transmitting MIGHT get intercepted, but at least you would know about it.
I briefly toyed with the idea of creating almost the exact same service - even down to using the URL hash to hide the secret. But at the end of the day, the concept has too many flaws for the security conscious and is too annoying to use for the layman.
https://github.com/abhishekkr/dory
* this is a secret sharing service for masses, where you don't need to be authenticated at service to store and share secret
* anyone with access to service can upload a secret and share the token with people they wanna share it
* if accessed without an explicit retention parameter, the secret gets purged on first fetch
* if stored in cache mode, it self expires after a TTL if not accessed for that duration
* even service admin can't decipher a secret posted by any user
Regarding paid service you write:
> If you already like this service, I am sure you will love the next version! The next version will include paid features, but signing up now you will get two months of premium features once they are ready. By signing up you also accept I will send you occasional emails when new stuff happens, such as premium features. I will never sell nor give your email to anyone, and I will send 2 emails maximum per month.
Its unclear what I'm signing up for. Am I signing up for the service or newsletter? I would suggest you phrase it as notify me of version 2.0 or something similar.
Great suggestion, I'll rephrase it.
I made a pastebin years ago that does similar using an anchor tag for the key, except it doesn’t guarantee deletion. https://paste.sh
I’ve been thinking about making it more secure using service workers (something like a service worker combined with resource signing, so it can be cached in browsers and people have to explicitly “upgrade” — along with the hash of the script shown, which can be verified with a reproducible build from a git revision hash).
Woa https://paste.sh is awesome. I love it. Super minimalistic. I wouldn't use it for sharing passwords, but using it for sharing notes and permanent things could be pretty nice. Right now I use Google Docs and hackmd, but they are not encrypting stuff. How does it work with multiple users online?
How I use instapass.io is sending an email/slack/telegram/etc. with the password in instapass. This way your password isn't stored on a email/slack/etc.. server in clear text forever. It also makes it possible to see if an attacker opened the password and take appropriate action. There is a slim risk of an MIIM where you edit the link super fast and have control over messaging service. This is exactly what @johnmarcus wrote. If you don't trust my service then you can just keep the password in Instapass and the other login info (url to login, email, username, etc..) inside the email. How should I know what you sent a password to? I think that's a better choice than sending login info in clear text.