
Show HN: Instantly pass your passwords securely - pinehqcom
Hey HN!<p>I made a service to share passwords easy and secure but never promoted it. 
It&#x27;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&#x27;t even be able to see what you wrote.<p>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&#x27;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&#x27;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.<p>Martin.
======
mike-cardwell
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.

~~~
z3t4
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.

~~~
mattigames
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.

~~~
jrockway
You also have to trust yourself! Many people have given up their encrypted
messages after having a few too many fermented malt beverages!

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

~~~
mattigames
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)

~~~
hagreet
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.

~~~
pinehqcom
Exactly exactly. I made sure to be resilient to Google bots/Virus Scanners by
doing some fancy javascript tricks

------
stabbles
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?

~~~
imglorp
One would hope something like Diffie-Hellman was used.

~~~
ygjb
"one would hope" \- aspirational security!

------
hagreet
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?

~~~
ryandvm
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.

------
philshem
[https://instapass.io/](https://instapass.io/)

~~~
pinehqcom
Thanks :)

------
Pirate-of-SV
It's like yopass[1]?

[1] [https://github.com/jhaals/yopass](https://github.com/jhaals/yopass)

~~~
pinehqcom
Woaa yea very similar and even the name is similar. It didn't exist when I
started the project. Looks nice.

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

------
zhynn
[https://sharelock.io/](https://sharelock.io/)
[https://github.com/auth0/sharelock](https://github.com/auth0/sharelock)

~~~
prophesi
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.

~~~
hagreet
I don't understand how this relates to the original post. ShareLock is not
end-to-end encrypted.

~~~
prophesi
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.

------
abionic
wrote an OSS `Dory` using golang, this for similar self-hosted use-case a
while back

[https://github.com/abhishekkr/dory](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

~~~
pinehqcom
Very nice. I love your Dory mascot!

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

~~~
pinehqcom
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.

------
dgl
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](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).

~~~
pinehqcom
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](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?

------
dangrairo
Pretty old idea. I'd go for compliance and tested
[https://privnote.com/](https://privnote.com/)

~~~
pinehqcom
Didn't know it existed when I made
[https://instapass.io](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.

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

~~~
pinehqcom
I am not following, could you elaborate a bit more?

------
atilla_bilgic
Since I have found, Keybase is my favorite for this kind of situations.
[https://keybase.io](https://keybase.io)

~~~
pinehqcom
KeyBase seems nice but a total different usecase I would argue.

------
MHM5000
And why should we trust a closed-source service?

~~~
pinehqcom
All the encryption part is javascript and visible in the browser. Go nuts

------
notlukesky
You are sharing messages in fact with different timeouts.??

~~~
pinehqcom
Exactly. Either a message expires or it get's viewed.

------
samdung
What kind of client side encryption does this use?

~~~
stabbles
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.

~~~
johnmarcus
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.

------
NudaVeritas
I recommend [https://nachricht.co](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)

~~~
GlitchMr
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.

~~~
pexooo
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.

