browserpass/browserpass-legacy

No obvious (or even possible?) way to logout

ipundit opened this issue · 4 comments

General information

  • Operating system + version: All
  • Browser + version: All

Exact steps to reproduce the problem

  1. Attempt to login to any site and enter your master password
  2. Now try to logout (How? Is this even possible? At the very least, give instructions of how to logout in the documentation)
  3. So close the browser and assume that you've logout.
  4. Restart the browser and attempt to login to any site. You do not need to re-enter your master password, and are therefore still logged in.

What should happen?

  1. You should be able to logout :). If this feature really doesn't exist yet, then I would suggest something simple like this:
    logout

Typing logout <enter> would logout. The next time the user attempts to login to a form, he has to enter his master password again

  1. Logout on browser close and provide the user option to toggle this preference. Some users like it, and some do not. As to whether "Logout when you close the browser" should be checked by default or not, the behavior for current users is to leave it unchecked and thus this would be a non-breaking change for them when upgrading. I would personally prefer the opposite, but there's arguments for checking and unchecking this box, so it should be left to the user rather than having personal preferences dictate this policy one way or another.

There is no concept of login and logout in browserpass itself, what you are probably referring to is the locking and unlocking of your gpg key. Browserpass is not managing your gpg sessions, it is handled by your gpg-agent and how you configure it on your own system.

One brutal way to "log out" is to kill gpg-agent process, a better way is to configure timeouts in your $HOME/.gnupg/gpg-agent.conf, see options --default-cache-ttl and --max-cache-ttl.

If you own a yubikey, you can additionally configure it to wait for a physical touch (or even ask for PIN) as a confirmation before unlocking the credentials, or once per session. But again, all of this is out of scope of browserpass, it respects your configuration of gpg and gpg-agent.

Ok thanks for the clarification. My 2 cents is to at least state this in the documentation, as it was not obvious to me and I need to refactor my .password-store with this revelation. For example, I have private notes that having nothing to do with logging in to websites, and did not expect that logging into a website through browserpass would allow gpg -d not-a-website to decrypt as a side-effect of logging into a site through browserpass.

Here's another use case for your consideration:

  1. Sammy the son wants to play a game, but needs Fred the father to unlock a feature for him
  2. Sammy calls Fred over and convinces him to pay for the feature
  3. Fred logs in to his banking site in another tab, or even a different browser to buy the feature, and is required to unlock his gpg keyring using his master password which Sammy does not have access to. Sammy instead has his own sets of passwords in his own password-store, which is separate from Fred's password store. Having color coded logins for different accounts is a nice way to distinguish their separate logins (issue #270).
  4. Fred logs out the bank site and closes the tab after purchasing. He needs to be able to logout his browserpass account or else....
  5. Sammy opens that same banking site and auto-fills in Fred's banking info and bad things happen from there...
  6. If you choose to logout from all accounts (recommended) upon logout, Sammy will have to log back in to play his game. That's fine, Sammy logs in to browserpass and continues on with access to only his keyring, not Sam's keyring.

Being logged into multiple accounts at the same time is wonderful (and AFAIK, a unique feature to browserpass), but if the user does not understand what is happening, bad things can happen. Perhaps the default, or at least toggleable behavior upon install would be create a new key-pair for the user after asking him to choose a master password, and then isolating his browser's passwords into a separate password-store by default. This has the desired side-effect of having everything "just work" upon install, rather than relying on users to manually set up all the dependencies. Most Windows users would not be able to do that, and therefore, would not use browserpass as it wouldn't work for them out-of-the-box.

If advanced users want to import or move logins from their existing keystore into this browserpass keystore, then they can do so, but they do it while explicitly understanding the security implications.

@ipundit you can use different gpg keys to lock different password stores. If you want to have the same key encode your entire password store, change the default-cache-ttl and max-cache-ttl keys in your gpg-agent.conf to whatever you think best. You'll have to enter your password upon every request for passwords, but it's the safest. Else use a different password store for all your banking needs.

My two cents are that I use different keys for storing (private) documents, signing emails, and using my password store. If you fear a malicious actor with physical access to your device, the recommended way of doing things is to kill gpg agent before handing over your computer to anyone else. The command to do so is gpgconf --kill gpg-agent. This has the effect of "logging out" as it is.

Love the scenario 😃

I see why you are asking these questions (and by the way, please continue sharing your ideas), but I'm a bit hesitant to go into describing how to create and configure password store because browserpass is meant to be only a visual extension over the pass. Even though the code doesn't explicitly depend on the pass executable anymore, the idea always was that browserpass is just another frontend for the password store that you use and manage with pass. Your scenario could be rephrased as "Fred the father unlocks password store with pass show personal/bank.com" and all the issues still remain, which indicates to me that this scenario is not really about the browserpass.

What I'm trying to say is that in this project we should document what we built on top of pass, but make it clear for users that they need to learn about pass for how to manage the password store itself and how to configure gpg.