Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] synchronized unlocking with desktop client #215

Closed
julianpoemp opened this issue Jan 3, 2019 · 7 comments
Closed

[feature request] synchronized unlocking with desktop client #215

julianpoemp opened this issue Jan 3, 2019 · 7 comments

Comments

@julianpoemp
Copy link
Member

It would be very nice if the browser addon could be synchronized with the desktop client so that a user only has to authenticate once.

Situation

Typing in the password twice (in the desktop client and browser addon) is not very user-friendly: if a user has more than three vaults he or she has to type in the passwords three times for the desktop client and three times each browser used. After the browser is closed and reopened the user has to type in the passwords again although the vaults in the desktop client are already unlocked.

Suggestion

After typing in the passwords in the desktop client the browser addon could send a request to the client in order to check if the vaults are already unlocked. If yes, the vaults could be unlocked in the browser and the user does not have to retype the passwords. If no, the user can type in the passwords. The browser addon could send the passwords to the client (if running). If the client receives this requests the vaults in the desktop client could be unlocked, too.

Security

Encryption of the passwords

The passwords for the transport from desktop-client to the browser addon could be encrypted using an auto-generated encryption key that is a auto-generated after the user want to use this function. In a window of the client the encryption key is displayed and should be inserted to the browser addon (copy&paste to the settings). This key is used for symmetric encryption of the master passwords.

Restrict the access to the desktop client

If the desktop client is meant to be a HTTP-Server, the access to the desktop client could be restricted to localhost and a specific port (perhaps you are already doing this :))

@perry-mitchell
Copy link
Member

Interesting idea.. I mean we have the secure-file-host managing the transfer of local files to the browser extension, so this bridge could be extended to handle this. We could also make it 2 way as well (desktop unlocks browser, browser unlocks desktop).

My concern here is the security.. transferring the master password to the desktop application is obviously very dangerous (and we don't currently do this with the secure-file-host). We also need to consider if this is really worth the effort. I'd like to see some votes here before we consider undertaking such a feature..

@julianpoemp
Copy link
Member Author

@perry-mitchell I hope that other people like that idea, too.
@other_people: Please upvote! 😄

@neojp
Copy link
Contributor

neojp commented Jul 13, 2019

I would like to add that after creating a new entry in the Browser if the Desktop app is unlocked, it would be nice to refresh it to reflect the fact that a new login has been added.

Right now I have to lock and unlock the Desktop archive over and over to confirm it was saved correctly.

@perry-mitchell
Copy link
Member

perry-mitchell commented Jul 13, 2019

refresh it to reflect the fact that a new login has been added.

I'm not sure this is related, @neojp - This issue is for unlocking vaults in 2 separate applications at the same time. Your issue, as I understand, would be related to #686 I believe.

@perry-mitchell
Copy link
Member

@julianpoemp I'm going to close this for now, as I don't see a way to handle this without transferring the master password across the wire via the secure-file-host. I don't like that idea, and think the result wouldn't be worth the risk. If you come up with another way to do this securely, we'll consider it. For now I don't think this is a direction we're willing to go, sorry.

@julianpoemp
Copy link
Member Author

@perry-mitchell I understand your concerns. But I still think it's a good idea in terms of user experience. But the problem are security issues coming up with this idea. I continue thinking about a solution. Perhaps, there is any secure way and it can be implemented in the future.

@perry-mitchell
Copy link
Member

Perhaps, there is any secure way and it can be implemented in the future

I wholeheartedly hope so - usability is extremely important, but just less so than security. If you come up with a secure way to handle such a process please don't hesitate in mentioning it. I'd happily reopen or accept a new issue on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants