Show HN: Pass.sh – simple, secure, password sharing service(pass.sh)
pass.sh
Show HN: Pass.sh – simple, secure, password sharing service
https://pass.sh
10 comments
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..
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..
> 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.
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.
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.
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.
Has little or no server side validation? (form prompts for min 1), I shared 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. :)
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.
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.
Name kind of conflicts with Pass (password-store). https://www.passwordstore.org
This is a neat little application! Would not use it for passwords, but like the idea of temporary snippets of text
Why no Unicode support?
You should definitely checkout Shamir's Secret Sharing.
This looks just like pwpush. Have you seen pwpush.com?
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 ;)
@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...
[2] https://www.troyhunt.com/weekly-update-64/
[3] https://www.lastpass.com/
[4] https://1password.com/
[5] https://www.dashlane.com/
[6] https://keepersecurity.com/
[7] https://www.virtru.com/
[8] https://www.virtru.com/client-side-encryption/
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...
[2] https://www.troyhunt.com/weekly-update-64/
[3] https://www.lastpass.com/
[4] https://1password.com/
[5] https://www.dashlane.com/
[6] https://keepersecurity.com/
[7] https://www.virtru.com/
[8] https://www.virtru.com/client-side-encryption/
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-...) 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.
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.
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.
-----------------------
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.
Thanks for being the only sane person in this thread.
Your comment seems incredibly shortsighted and I very much question your first hand experience.
> First, users should NEVER share their passwords with anyone.
Heh, every company I have worked for, I have had to share passwords to tools in some form or the other - private keys, certificate files, shared account passwords to name a few.
> 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.
So, you are willing to "vouch" for some random closed source software without every seeing the code and yet here you vilify code that is open.
Again, I very much question your first hand experience in security or real world software. Not sure what your objective with your comment is but it is hardly educational.
> First, users should NEVER share their passwords with anyone.
Heh, every company I have worked for, I have had to share passwords to tools in some form or the other - private keys, certificate files, shared account passwords to name a few.
> 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.
So, you are willing to "vouch" for some random closed source software without every seeing the code and yet here you vilify code that is open.
Again, I very much question your first hand experience in security or real world software. Not sure what your objective with your comment is but it is hardly educational.
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.
----------------------- > Heh, every company I have worked for, I have had to share passwords to tools in some form or the other - private keys, certificate files, shared account passwords to name a few.
See my comment acknowledging that I was flat out wrong to argue that users never have a need to share passwords: https://news.ycombinator.com/item?id=15996129.
As a developer needing to share passwords, there are plenty of secure ways to achieve sharing passwords without resorting to using email. For example, Hashicorp Vault [1] is a free and secure option which has gained lots of traction in the marketplace in recent years.
> So, you are willing to "vouch" for some random closed source software without every seeing the code and yet here you vilify code that is open.
It is quite widely accepted that password managers are the best practice for sharing passwords. The SecurityPlanner project recommends LastPass [2], has some very well respected folks from the security community on their advisory and peer review boards [3], including Bruce Schneier, Gary Belvin, and Iulia Ion. Also, the EFF recommends using a password manager [4]. Troy Hunt has an article explaining and recommending password managers (e.g. 1password) [9].
Also, most of the mainstream commercial password managers publish white papers on their security architecture and often undergo pen tests, security audits, etc. For example, see [5] [6] [7] [8].
Password managers utilize end to end encryption by encrypting the password on your device before sending it to their servers (for syncing between devices, etc). Without seeing the source code, you can observe the traffic over the wire to prove that these password managers are implementing end to end encryption and only sending cipher text over the wire to the remote server. In contrast, the Pass.sh service sends plain text passwords over the wire to their servers, which means that their servers have access to the plain text password.
[1] https://www.vaultproject.io/ [2] https://securityplanner.org/#/tool/password-manager [3] https://securityplanner.org/#/who-we-are [4] https://ssd.eff.org/en/node/23/ [5] https://lastpass.com/enterprise/security [6] https://support.1password.com/security-assessments/ [7] https://keepersecurity.com/security.html [8] https://www.dashlane.com/download/Dashlane_SecurityWhitePape... [9] https://www.troyhunt.com/only-secure-password-is-one-you-can...
----------------------- > Heh, every company I have worked for, I have had to share passwords to tools in some form or the other - private keys, certificate files, shared account passwords to name a few.
See my comment acknowledging that I was flat out wrong to argue that users never have a need to share passwords: https://news.ycombinator.com/item?id=15996129.
As a developer needing to share passwords, there are plenty of secure ways to achieve sharing passwords without resorting to using email. For example, Hashicorp Vault [1] is a free and secure option which has gained lots of traction in the marketplace in recent years.
> So, you are willing to "vouch" for some random closed source software without every seeing the code and yet here you vilify code that is open.
It is quite widely accepted that password managers are the best practice for sharing passwords. The SecurityPlanner project recommends LastPass [2], has some very well respected folks from the security community on their advisory and peer review boards [3], including Bruce Schneier, Gary Belvin, and Iulia Ion. Also, the EFF recommends using a password manager [4]. Troy Hunt has an article explaining and recommending password managers (e.g. 1password) [9].
Also, most of the mainstream commercial password managers publish white papers on their security architecture and often undergo pen tests, security audits, etc. For example, see [5] [6] [7] [8].
Password managers utilize end to end encryption by encrypting the password on your device before sending it to their servers (for syncing between devices, etc). Without seeing the source code, you can observe the traffic over the wire to prove that these password managers are implementing end to end encryption and only sending cipher text over the wire to the remote server. In contrast, the Pass.sh service sends plain text passwords over the wire to their servers, which means that their servers have access to the plain text password.
[1] https://www.vaultproject.io/ [2] https://securityplanner.org/#/tool/password-manager [3] https://securityplanner.org/#/who-we-are [4] https://ssd.eff.org/en/node/23/ [5] https://lastpass.com/enterprise/security [6] https://support.1password.com/security-assessments/ [7] https://keepersecurity.com/security.html [8] https://www.dashlane.com/download/Dashlane_SecurityWhitePape... [9] https://www.troyhunt.com/only-secure-password-is-one-you-can...
Its nice of you to make this long winded diatribe about security which you have gotten completely wrong.
> 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
Me thinks you don't quite understand what end to end encryption means. When you visit pass.sh it forces you onto a TLS session. Anything you enter into that box is encrypted in transit. The data is encrypted in the database, and the password deletes itself from the database automatically after X views and/or X days.
I expected more from a "senior engineer at Virtu" but now I know what company to stay away from. Thanks.
> 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
Me thinks you don't quite understand what end to end encryption means. When you visit pass.sh it forces you onto a TLS session. Anything you enter into that box is encrypted in transit. The data is encrypted in the database, and the password deletes itself from the database automatically after X views and/or X days.
I expected more from a "senior engineer at Virtu" but now I know what company to stay away from. Thanks.
Also as others have pointed out, the purpose of the project is to introduce a security control to curtail the sharing of plaintext passwords via communications channels WHICH PEOPLE ALREADY DO. At my company just last week a vendor emailed us ftp credentials in plain text. If they were to use pass.sh (that they can operate themselves) it greatly reduces the risk of those credentials being compromised due to privilege escalation from a compromised email account or the likes. This is a HIGHLY simply concept the aims to solve a RAMPANT security problem in large organizations.
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.
-----------------------
Creating a secure connection between the browser and your server using TLS is clearly important, but does not provide end to end encryption.
First, let’s agree on the definition of end to end encryption.
On Wikipedia article [1]: > End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation
On the Signal homepage [2]: > Signal messages and calls are always end-to-end encrypted and painstakingly engineered to keep your communication safe. We can't read your messages or see your calls, and no one else can either.
End to end encryption means that the contents of a message is encrypted by a sender before it leaves the sender’s device and can ONLY be decrypted by the intended receiver. The application servers, communication channel, unintended recipients, etc all do not have the ability to read the plain text content of the message.
In the context of the Pass.sh application, there are three (3) parties: the user who wants to send a password to someone (“the sender”), the Pass.sh application servers (“the servers”), and the user who the sender wants to send the password to (“the receiver”). This is the data flow for the Pass.sh application:
1. the sender enters some plain text content into the text box on the website 2. the plain text content is sent to the servers via a secure TLS connection 3. After resolving TLS on the servers, the plain text is available to the application, where it is encrypted and stored in a database. 4. The application presents a link to access the plain text to the sender. 5. The sender emails the link to the recipient. 6. The receiver reads the email and clicks on link. 7. Without authenticating, the receiver is shown the plain text.
In order for this to be end to end encryption, only the sender and the receiver should be able to read the plain text password. However, since the Pass.sh servers can also read the plain text content, this solution, by definition, does not use end to end encryption.
In step #3, the plain text is available to the servers, which means that it is also available to a huge range of potential parties: whomever is running the servers, application audit logs, any front end proxies that might be in use (e.g. Cloudflare, AWS, etc), a third party metrics or logging service that the servers might be using, or the servers could be flat out malicious and send the plain text off to someone collecting passwords for nefarious use. All of these are completely transparent to the user, so the password could be compromised even if the sender and the receiver both observe the “correct” behavior; they have zero guarantees that the password has not been compromised as soon as it is sent to the servers.
It would be a huge improvement to the security UX if the Pass.sh homepage made it clear to users that the servers can read the plain text password that they enter into the input box. Also, it would likely help users if Pass.sh provided much more written explanation about the use-cases that it believes Pass.sh can securely address.
---------------
Response to potential questions/comments:
“Well, okay, we might have the plain text password in step #3, but we don’t know the username, so it’s fine”.
Correct, you only have the password, but that is already a huge problem. For example, hackers could easily cross reference the provided plain text password against previously obtained data breaches from other services to check for positive hits. Users reuse passwords all the time (even though they shouldn’t) and the chance of getting a positive hit on a user provided password is likely much higher than brute forcing.
“Well, the code is open source, so I know that it is not doing anything malicious and can be trusted.”
Assuming that we agree that end users cannot trust versions of Pass.sh which are hosted by an unknown party because they cannot guarantee which code is actually powering the service, the argument could be made that Pass.sh is safe if you run the software yourself because it is open source and you can review the software. Of course, if you review the application code yourself and are confident in the security of the service, that is an improvement for you as a developer. However, this will only increase the trust level for users who know for a fact that you are trustworthy and are hosting the version of Pass.sh with which they are interacting.
The Pass.sh service is publicly available on the internet for anyone to use and claims on the homepage that it is “Secure Password Sharing Service”. End users cannot trust that the publicly available version is secure because they cannot guarantee that the code powering that service matches the open source code available for review. If the users could verify that the end to end encryption was taking place on their device before any data was sent over the wire, that would drastically reduce this risk. This is the main reason that I think the Pass.sh project would better serve end-users by not providing a publicly hosted version and instead instead targeting developers who have the ability to audit the software themselves to run it if they believe that it solves a problem for them or their organization.
“Using Pass.sh is good because it is more secure than sending a password via normal email, which is what users are doing right now, because the password is deleted after X time or Y views.”
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.
------------
Security UX
The home page has the text “go ahead, i'm not looking…” on it. While this might be intended as cheeky marketing talk, to me this presents a lack of seriousness and trust. First, as covered above in detail, the Pass.sh servers are in fact looking because they can see the plain text of the password. Second, normal non-technical users may read that text and believe that Pass.sh truly cannot look at their password. This is setting up a false sense of security that normal non-technical users likely do not understand the risks they are taking.
It would be great if Pass.sh provided an explanation of the security architecture for users to review. This would help people understand how the service functions and they could make a more informed decision whether it met their needs or not. Currently, someone would need to either have a technical background and/or audit the code in order to get even an overview of how the service works.
[1] https://en.wikipedia.org/wiki/End-to-end_encryption [2] https://signal.org/
-----------------------
Creating a secure connection between the browser and your server using TLS is clearly important, but does not provide end to end encryption.
First, let’s agree on the definition of end to end encryption.
On Wikipedia article [1]: > End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation
On the Signal homepage [2]: > Signal messages and calls are always end-to-end encrypted and painstakingly engineered to keep your communication safe. We can't read your messages or see your calls, and no one else can either.
End to end encryption means that the contents of a message is encrypted by a sender before it leaves the sender’s device and can ONLY be decrypted by the intended receiver. The application servers, communication channel, unintended recipients, etc all do not have the ability to read the plain text content of the message.
In the context of the Pass.sh application, there are three (3) parties: the user who wants to send a password to someone (“the sender”), the Pass.sh application servers (“the servers”), and the user who the sender wants to send the password to (“the receiver”). This is the data flow for the Pass.sh application:
1. the sender enters some plain text content into the text box on the website 2. the plain text content is sent to the servers via a secure TLS connection 3. After resolving TLS on the servers, the plain text is available to the application, where it is encrypted and stored in a database. 4. The application presents a link to access the plain text to the sender. 5. The sender emails the link to the recipient. 6. The receiver reads the email and clicks on link. 7. Without authenticating, the receiver is shown the plain text.
In order for this to be end to end encryption, only the sender and the receiver should be able to read the plain text password. However, since the Pass.sh servers can also read the plain text content, this solution, by definition, does not use end to end encryption.
In step #3, the plain text is available to the servers, which means that it is also available to a huge range of potential parties: whomever is running the servers, application audit logs, any front end proxies that might be in use (e.g. Cloudflare, AWS, etc), a third party metrics or logging service that the servers might be using, or the servers could be flat out malicious and send the plain text off to someone collecting passwords for nefarious use. All of these are completely transparent to the user, so the password could be compromised even if the sender and the receiver both observe the “correct” behavior; they have zero guarantees that the password has not been compromised as soon as it is sent to the servers.
It would be a huge improvement to the security UX if the Pass.sh homepage made it clear to users that the servers can read the plain text password that they enter into the input box. Also, it would likely help users if Pass.sh provided much more written explanation about the use-cases that it believes Pass.sh can securely address.
---------------
Response to potential questions/comments:
“Well, okay, we might have the plain text password in step #3, but we don’t know the username, so it’s fine”.
Correct, you only have the password, but that is already a huge problem. For example, hackers could easily cross reference the provided plain text password against previously obtained data breaches from other services to check for positive hits. Users reuse passwords all the time (even though they shouldn’t) and the chance of getting a positive hit on a user provided password is likely much higher than brute forcing.
“Well, the code is open source, so I know that it is not doing anything malicious and can be trusted.”
Assuming that we agree that end users cannot trust versions of Pass.sh which are hosted by an unknown party because they cannot guarantee which code is actually powering the service, the argument could be made that Pass.sh is safe if you run the software yourself because it is open source and you can review the software. Of course, if you review the application code yourself and are confident in the security of the service, that is an improvement for you as a developer. However, this will only increase the trust level for users who know for a fact that you are trustworthy and are hosting the version of Pass.sh with which they are interacting.
The Pass.sh service is publicly available on the internet for anyone to use and claims on the homepage that it is “Secure Password Sharing Service”. End users cannot trust that the publicly available version is secure because they cannot guarantee that the code powering that service matches the open source code available for review. If the users could verify that the end to end encryption was taking place on their device before any data was sent over the wire, that would drastically reduce this risk. This is the main reason that I think the Pass.sh project would better serve end-users by not providing a publicly hosted version and instead instead targeting developers who have the ability to audit the software themselves to run it if they believe that it solves a problem for them or their organization.
“Using Pass.sh is good because it is more secure than sending a password via normal email, which is what users are doing right now, because the password is deleted after X time or Y views.”
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.
------------
Security UX
The home page has the text “go ahead, i'm not looking…” on it. While this might be intended as cheeky marketing talk, to me this presents a lack of seriousness and trust. First, as covered above in detail, the Pass.sh servers are in fact looking because they can see the plain text of the password. Second, normal non-technical users may read that text and believe that Pass.sh truly cannot look at their password. This is setting up a false sense of security that normal non-technical users likely do not understand the risks they are taking.
It would be great if Pass.sh provided an explanation of the security architecture for users to review. This would help people understand how the service functions and they could make a more informed decision whether it met their needs or not. Currently, someone would need to either have a technical background and/or audit the code in order to get even an overview of how the service works.
[1] https://en.wikipedia.org/wiki/End-to-end_encryption [2] https://signal.org/
Interesting, but otherwise useless project
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.