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