5 ms·

@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 t

@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-sharing-passwords/ https://www.troyhunt.com/the-trouble-with-politicians-sharin... [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 9y ago
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-passwords.html/ 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.
- jc_sec 9y ago
  Thanks for being the only sane person in this thread.
- conorgil145 9y ago
  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.

jonnycomputer 9y ago

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-passwords.html/ 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.

jc_sec 9y ago
Thanks for being the only sane person in this thread.
conorgil145 9y ago
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.