
Show HN: Pass.sh – simple, secure, password sharing service - jc_sec
https://pass.sh
======
tatersolid
Simple, yes.

Secure, not so much.

Saying “I used encryption” doesn’t make it secure; password distribution is a
_key management_ problem which is not solved by encryption.

Your secret is stored in a DB you don’t own, and the encryption keys are on a
random third party’s servers.

No way to verify anything is actually deleted.

Email filters will visit the links if you send the URL via email, further
exposing the password.

Even if sharing a limited-time “reset” password that is forced to be changed
immediately there are tons of simpler and more secure options for
distribution.

I don’t know what scenarios this is useful for in the real world, but I
certainly don’t advise using it for anything even approaching important.

~~~
jc_sec
Hi, author here...

Firstly, this project is open source. If you suspicious of where the data is
being stored or my intentions, you are free to fork and run it yourself.

That being said.. I am not claiming to have achieved some novel security
accomplishment. Yes, this is a simple symmetric encryption using a vetted
crypto lib, backed by a key value store, and using UUID4 to generate the
links.

Its a trade of for convenience and security. It's better than emailing
passwords in plaintext and makes security more accessible to folks who dont
have the time/incinlination/technical ability to set up keybase and/or
estbalish PKI for sharing secrets.

Understand the audience this is targeting..

~~~
tatersolid
> It's better than emailing passwords in plaintext

How exactly? The link is completely equivalent to the password from a security
perspective. The whole system adds zero security over sending the password in
clear text.

At $dayjob we have the help desk staff give initial passwords on a small card
in person, and the system forces a change on first use.

For remote users the help desk uses a voice call, calling the user on a number
provided by HR, and asking a few questions before giving the initial password.

This system is not uncommon and has been used by organizations for decades
without being a commonly exploited vulnerability. It is more secure than
pass.sh as it adds physical or at least weak verbal authentication. It is also
much simpler, requiring no trusted third parties, and does not expose the
secrets on the Internet at all.

~~~
jc_sec
Lol, its not equivalent because its a link that deletes itself automatically
after X days and X views. In a scenario where an email/slack/etc account
becomes compromised down the road a password sent in plaintext is immediately
compromised where as a password shared with pass.sh has expired and is no
longer a valid link.

If you cant understand the very basic security control there then I really
can't help you. You sound like someone who has been stuck in IT too long.

You are kidding yourself if you think relying on over a support agent to
verify identity is better than the solution here. Humans are inherently
fallable as social engineering has proven time and again.

------
iKlsR
Has little or no server side validation? (form prompts for min 1), I shared
[https://pass.sh/show/2582dbae-5450-4a74-a758-152cdac1c049](https://pass.sh/show/2582dbae-5450-4a74-a758-152cdac1c049)
with delete after -1 views (simple inspect and edit). It does work to some
extent tho as I the link comes up empty. :)

~~~
iKlsR
Had a look at the code, no validation other than on the client. Sidenote,
forgot how clean, minimal and expressive Python can be, was a pleasure to
quickly grok.

~~~
jc_sec
this comment made my day... :)

but yeah that backend validation is on my radar.

Thanks for checking me out

------
tugberkk
I see how this is seen as useless and non-secure; and there is logic behind
it. But also, as the author suggested this may be a better solution rather
than sending e-mails or writing passwords onto a text.

Also, since it is open source as the author stated, you can run it yourself on
your platform. At least you are going to reduce the number of 3rd parties
involved.

------
bhhaskin
Name kind of conflicts with Pass (password-store).
[https://www.passwordstore.org](https://www.passwordstore.org)

------
jesperlang
This is a neat little application! Would not use it for passwords, but like
the idea of temporary snippets of text

------
wrinkl3
Why no Unicode support?

------
B3QL
You should definitely checkout Shamir's Secret Sharing.

------
mrdavid
This looks just like pwpush. Have you seen pwpush.com?

~~~
jc_sec
Yes, that was the inspiration for this project. I've used pwpush and even
suggested some changes to that project. I wanted something more lightweight
(non rails) and simpler to integrate. Nothing against pwpush, just my version
of it ;)

~~~
mrdavid
Understood. The thing I really like about pwpush is the Alfred integration. Do
you have any plans to do the same? Thank you

~~~
jc_sec
Haven't heard of this until now. Looks cool I'll check it out.

------
conorgil145
@jc_sec, I see that you commented that you're the author of this tool. I am
trying to wrap my head around why you created it, but am having a really
difficult time understanding the motivation. Perhaps, it was an educational
project for yourself to learn about working with crypto. If that was the case,
then I applaud your learning, but encourage you to treat such projects as
throw away learning experiences and not publish them. In fact, I think that
this tool is actually quite dangerous and it would be irresponsible to leave
it available online and encourage its use.

First, users should NEVER share their passwords with anyone. Ever. The entire
purpose of this tool is to encourage users to share their passwords, which is
the exact opposite behavior that any good security training program should be
teaching users. Any reason that someone offers to justify the sharing of a
password is simply a shortcoming in a specific piece of software supporting
business needs. Ironically, Troy Hunt had an article this week about password
sharing, which covers the topic well [1][2]. I won't rehash the argument here,
but do please read his post.

Second, the tool offers zero security benefit over sending a password via
email.

> It's better than emailing passwords in plaintext

No it is not.

The content entered into the text box is accessible simply by visiting a link,
which means that the data is not end to end encrypted. Any email containing
the link is equivalent to containing the password because someone simply needs
to click on the link to obtain the password. It doesn't matter which cipher
you use, which library you use, where you store the keys, etc because the
server running the application has the ability to read the plain text content.
This tool does _not_ provide end to end encryption, which is required for any
reasonable password management tool.

> makes security more accessible to folks who dont have the
> time/incinlination/technical ability to set up keybase and/or estbalish PKI
> for sharing secrets.

Again, no it does not. This tool does not offer any security value, so it
cannot make security more accessible to users. Users do not need to know how
to setup Keybase or PKI in order to use other existing secure tools. For
example, users should utilize software specifically built for managing
passwords, such as LastPass [3], 1Password [4], Dashlane [5], Keeper [6], or a
vetted open source alternative.

I know a thing or two about building end to end encryption systems based on my
first hand experience as a Senior Engineer at Virtru [7], a commercially
available end to end email encryption solution. I was one of the original
employees and helped design the fundamental security architecture, which has
been audited by respected independent third parties. You can read more about
Virtru's technology on their website [8].

Again, I do not know whether you truly think that this tool is secure, or if
you were just trying to educate yourself and develop some new skills working
with crypto libraries. Please realize that this feedback is not intended to
vilify, but to educate. Please consider taking this tool down and instead
promoting a secure alternative to password management to anyone who asks for
guidance on sharing passwords.

[1] [https://www.troyhunt.com/the-trouble-with-politicians-
sharin...](https://www.troyhunt.com/the-trouble-with-politicians-sharing-
passwords/)

[2] [https://www.troyhunt.com/weekly-
update-64/](https://www.troyhunt.com/weekly-update-64/)

[3] [https://www.lastpass.com/](https://www.lastpass.com/)

[4] [https://1password.com/](https://1password.com/)

[5] [https://www.dashlane.com/](https://www.dashlane.com/)

[6] [https://keepersecurity.com/](https://keepersecurity.com/)

[7] [https://www.virtru.com/](https://www.virtru.com/)

[8] [https://www.virtru.com/client-side-
encryption/](https://www.virtru.com/client-side-encryption/)

~~~
jonnycomputer
I think this is unduly harsh, and, frankly, ideologically rigid. The reality
is much different; users do find that they need to share passwords, and
they'll continue to do it whatever you say; in fact, applications like
LastPass recognize that password sharing
([https://blog.lastpass.com/2016/01/tips-for-securely-
sharing-...](https://blog.lastpass.com/2016/01/tips-for-securely-sharing-
passwords.html/)) is a real necessity, and they provide a means of doing so
_if everyone is in the LastPass ecosystem_.

It may be that password sharing is only necessary because of shortcomings in
the applications they use, but that ignores the fact that most end-users don't
have a way of changing those shortcomings (and sometimes, those shortcomings
are by design). Instead, users have to deal with the systems they do. End of
story.

You say that the tool provides no additional security value because all they
need is the link to obtain the password; but this ignores the fact that the
application is designed to delete the password after it has been obtained n
times, or after x days; the security hazard for most people is not
interception of the email en-route, but hacked accounts; unless that happens
in a very short window, this is quite a bit safer than sending it in plain
text _which is what they already do_.

~~~
conorgil145
After rereading my initial comment and the responses to it, I absolutely agree
that my tone was unduly harsh and condescending. I did not at all intend that
when I wrote the comment, but it was clearly the result regardless. I
apologize to everyone in this thread for not communicating my concerns more
constructively. I have tried to reply to each comment in a much more
constructive way.

\-----------------------

As far as sharing passwords, I was flat out wrong to argue that users do not
need to share passwords. As you point out, users may need to share passwords
because of the shortcomings in any given software because they might not have
an option to switch to a different solution. As part of educating users about
best practices, many courses educate users to not share their password with
corporate IT/support desks/bosses/coworkers/etc. I think that is the absolute
correct thing to teach to users so that the initial reaction to any request to
share a password is suspicion and hesitation. In the event that users DO have
a legitimate reason to share passwords, they should use a tool which
implements end to end encryption so that only the intended recipient can read
the plain text password. As you also highlight, most password managers provide
some ability to do just that.

The LastPass article that you linked to highlights the fact that, although
there are reasons to share passwords, users should do so securely:

> You don’t have to rely on insecure methods of sharing passwords, like
> through email, texting, or writing them down.

As far as the ephemerality of Pass.sh links, you are absolutely correct that I
neglected to consider that security benefit. I absolutely agree that the
ephemerality of messages on Pass.sh means that it is more secure to send a
password using Pass.sh than via normal email. However, this is missing the
point. Just because A is better than B does not mean that A is good. Sending
passwords via plain email and by Pass.sh link in an email are both insecure
methods of sharing passwords and end users should avoid them both. Instead,
they should use one of the many tools (e.g. password managers) which solve the
problem of sharing passwords with other people in a significantly more secure
way (e.g. end to end encryption). They could even use a free solution like
Signal [2] which provides end to end encryption. Yes, the password will stay
in the receiver’s message thread forever, but you have to trust the receiver
to send them a password via any channel in the first place.

I realize that users will continue to follow some bad habits in terms of
security regardless of my comments here in HN. However, I think one critical
component of solving the larger problem is education and developers play a
role in that education. When we build solutions that we claim are secure, we
should be upfront about explaining how they work, the appropriate use-cases
the tool is trying to solve, and the potential risks associated with using the
tool. Developers are in a unique position to answer those questions and normal
non-technical users are often not aware of the questions they should even be
asking in the first place.

------
rubatuga
Interesting, but otherwise useless project

