Show HN: Instantly pass your passwords securely
Hey HN!
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.
Don't forget to read all of the javascript loaded every time you use this website to verify that it hasn't had `$.get('?secret_msg=' + encodeURIComponent($('#id_text').val()))` or similar added to it.
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.
You not only have to trust the websites, you also need to trust your operating system, your web browser, and the web browser extensions. It's for example common for browsers to call home with anything you type/paste in the URL-bar. Both Chrome and Firefox did that last time I checked.
you forgot to mention you also need to trust the CPU, the motherboard among other hardware components, you also need to trust lack of cameras on the room you see the message among other physical eavesdropping.
You also have to trust yourself! Many people have given up their encrypted messages after having a few too many fermented malt beverages!
I feel like this should be a browser extension: Automatically checking resources for changes and blocking new versions until the diff has been approved
That's actually not a bad idea. You could add different kinds of auditors and see who approved it. I'll add that to my never-ending list of "Good Business Ideas When I have time"
All my JavaScript is self-hosted and easy to read. 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.
There is a way to make sure the website never changes without having to check each time, and that is to append it as a data:text/html link and add such link as a bookmark (example data:text/html,<script>alert('hi');</script>), as long as the script tags have SRI (Subresource Integrity Check[0])
[0] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
I'm sorry but this unfortunately is not a secure solution and should not be treated as such.
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.
Yeah, in its current implementation it isn't secure, but if you added SRI checks for each CSS and SCRIPT link and then converted the site to a data:text/html link to be added to the user's bookmark bar it would be secure (in the sense that after auditing the code once you can be sure it cannot be changed)
I think the most important point is, that this solution requires a way to securely transmit the generated link. As described in another comment by @ryandvm this has two advantages over transmitting the password directly: 1. It won't show up in logs or be otherwise accidentally stored. 2. If the link expires after a single use you get security in the covert model. However, this comes with problems because some tools like virus scanners automatically hit links.
Exactly exactly. I made sure to be resilient to Google bots/Virus Scanners by doing some fancy javascript tricks
For this reason I host all the JS/CSS myself and don't have any other JS running. I.e. no google analytics or ad shit.
It is secure. The password is not sent to my service. Try setup an `netcat -l -p 8000` and go into your browser and write `http://localhost:8000/#hi` You will see the hi is never sent to the server
It's insecure because anyone who intercepts the message can trivially decrypt it by pasting it into their browser.
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.
At least you'd know the message has been compromised, no? Although I guess a perp can feed you a different link and delay the realization.
It's not a perfect solution. As @dfalfndfk says you will know that you're eavesdropped.
This service is begging the question.
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?
One would hope something like Diffie-Hellman was used.
"one would hope" - aspirational security!
I don't understand the threat model here. The link needs almost the same kind of protection as the original password. The only difference is, that the link expires.
So how do you transmit those links securely and why didn't you use that for your passwords in the first place?
I think the key is that the message would be deleted by the server after ONE use. So... you send the link via whatever mechanism you want (Slack, SMS, email, etc.). If a man-in-the-middle intercepted it, they need to follow the link to decrypt it, thereby expiring the message. So if the recipient gets a dead link, then you know security has been compromised.
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://instapass.io/
Thanks :)
It's like yopass[1]?
[1] https://github.com/jhaals/yopass
Woaa yea very similar and even the name is similar. It didn't exist when I started the project. Looks nice.
Hey guys, thanks for all the comments. I'll try to address them before I am going to bed.
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.
https://sharelock.io/ https://github.com/auth0/sharelock
I'd like to hear HN's take on ShareLock. I think the service is ingenious; my only issues after using it for so long:
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.
I don't understand how this relates to the original post. ShareLock is not end-to-end encrypted.
It solves the issue of secret-sharing much better than any of the other proposed solutions here, including InstaPass. You can post the URL in a public channel with confidence, as even if an attacker accesses the URL, they have to verify themselves with their social identity to decrypt the data.
But yes, it's not end-to-end encrypted, so you're better off self-hosting your own instance of sharelock.
wrote an OSS `Dory` using golang, this for similar self-hosted use-case a while back
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
Very nice. I love your Dory mascot!
Cool product.
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.
Thanks bko! You're signing up for newsletter and get's notified when there's a version 2.0 and also get 2 months paid.
Great suggestion, I'll rephrase it.
It seems like this is relying on the server to delete the message when accessed?
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).
Yep. Right now I just override any message securely. I was thinking of doing something like having all the messages in memory and just wipe the memory there, but the problem with that approach is I can't tell people if it expired and thus you can't see if people eavesdrop.
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?
Pretty old idea. I'd go for compliance and tested https://privnote.com/
Didn't know it existed when I made https://instapass.io privnote looks nice and I would definitely use it before I made my own service. I am planning to add more features that hopefully will be useful for you guys.
What's wrong with this trusted-third-party type of services (where neither you nor service provider cannot prove your data can't be used maliciously) is that people get used to them (because "time and complexity"). And then malicious actors start asking email on signup and harvesting passwords.
I am not following, could you elaborate a bit more?
Since I have found, Keybase is my favorite for this kind of situations. https://keybase.io
KeyBase seems nice but a total different usecase I would argue.
And why should we trust a closed-source service?
All the encryption part is javascript and visible in the browser. Go nuts
You are sharing messages in fact with different timeouts.??
Exactly. Either a message expires or it get's viewed.
What kind of client side encryption does this use?
It's just some symmetric encryption with a randomly generated key (in the hash of the generated url).
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.
not really true. You can send the link via slack. the person would then need to actually be listening to your slack messages in real time, which is a threat but a very minor one. What this protects against is the real password being visible in Slack logs and archive history for all to see.
so, it doesn't solve every problem, but it does solve most real problems.
It's adding self-destructing messages, so there's that. But, yeah, the lack of protection from eavesdropping is a show stopper.
AES-128-CCM
So. Many. Problems. So. Much. Insecure.
Please don't be a jerk in HN comments, and especially not when someone is sharing their work. Would you mind reading https://news.ycombinator.com/showhn.html? Note these:
Be respectful. Anyone sharing work is making a contribution, however modest.
Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more.
When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.
Care to elaborate?
I recommend https://nachricht.co
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)
The messages AREN'T encrypted, they are very much visible with web developer tools, sent in plain text in requests. Ads can easily read messages (so you need to trust Google and random Google Ads users to not read messages in addition to the website owner... which is lol, not happening). This website is dangerous snake oil.
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.
It always depends on who you want to hide these messages from. Of course, end-to-end encryption is more secure than pure server-side encryption. But do you really need end-to-end encryption for such a webtool? After all, all TCP packets are already encrypted via TLS. The advantage of these web tools is in the temporary storage without being able to restore these messages, not hyper secure NSA-proof messaging.