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/