11–20 of 27 posts
This looks just like pwpush. Have you seen pwpush.com?
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.
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 ;)
Earlier quoted context omitted.
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 ;)
Understood. The thing I really like about pwpush is the Alfred integration. Do you have any plans to do the same? Thank you
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…
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 conve…
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.
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/
@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 pu…
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.
Earlier quoted context omitted.
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 conve…
> 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…
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.