browserpass-extension icon indicating copy to clipboard operation
browserpass-extension copied to clipboard

Browserpass ignores locked USB key on Firefox

Open mattst88 opened this issue 5 years ago • 10 comments

General information

  • Operating system + version: Gentoo/Linux
  • Browser + version: Chromium 81, Firefox 75
  • Information about the host app:
    • How did you install it? Via package manager
    • If installed an official release, put a version ($ browserpass --version): Browserpass host app version: 3.0.6
    • If built from sources, put a commit id ($ git describe --always):
  • Information about the browser extension:
    • How did you install it? Webstore
    • Browserpass extension version as reported by your browser: 3.4.1 for both Chromium and Firefox

Exact steps to reproduce the problem

  1. Encrypt passwords in pass database with two GPG encryption keys: one on a Nitrokey or similar, one as a backup which is stored on the system (to be used as an offline backup, presumably). Pass's .gpg-id file contains the encryption keys in order: (1) Nitrokey, (2) back up key

  2. With a locked Nitrokey, ask browserpass to fill in a password form.

What should happen?

With a locked Nitrokey browserpass should attempt to use the primary decryption key first (the Nitrokey) before falling back to the backup key.

What happened instead?

With the backup key is available on the system and the Nitrokey's decryption key locked:

  • On Firefox pressing requesting browserpass fill in a form (with CTRL+SHIFT+L) will pop up a GPG password dialog for the backup key, instead of asking for the Nitrokey's password.

  • On Chromium it asks for the Nitrokey's unlock password.

  • Using pass -c it asks for the Nitrokey's unlock password.

If the Nitrokey is already unlocked, then it fills in the password form correctly on both Chrome and Firefox using the decryption key from the Nitrokey.

I have no idea whether this is a bug in browserpass-extension or browserpass-native or Firefox or ..., but I do also see this behavior when using the PassFF browser extension as well in Firefox. It's not possible for me to test it in Chromium since PassFF does not support Chromium.

mattst88 avatar Apr 21 '20 19:04 mattst88

This is not a bug in Browserpass. We just call gpg directly via the native host to decrypt the file, and we do not specify which key to use - that's left for gpg to determine. If the behavior is different with Firefox vs anything else, then you might have a different gpg config in scope for Firefox's execution environment.

Which ebuild did you use for Firefox, and how is it installed - just directly from portage, or have you containerised it somehow?

erayd avatar Apr 21 '20 20:04 erayd

Thanks for the response. Firefox is installed from portage, www-client/firefox-75.0. Any guidance on further debugging would be most welcome.

mattst88 avatar Apr 21 '20 20:04 mattst88

Any chance you could install firefox-bin and let me know if you see the same behavior with that one?

Mainly because I don't want to spend several hours compiling Firefox, and that way we'll still be comparing the same package.

erayd avatar Apr 21 '20 20:04 erayd

Also, how are you launching it?

erayd avatar Apr 21 '20 20:04 erayd

Just tried with www-client/firefox-bin-75.0 on a completely new profile and the same behavior exists. I'm launching browserpass with CTRL+SHIFT+L.

mattst88 avatar Apr 21 '20 20:04 mattst88

Thanks. Are you willing to post your gpg config? Will try to replicate it here.

erayd avatar Apr 21 '20 20:04 erayd

Sure, here it is (~/.gnupg/gpg.conf):

default-key 3BB639E56F861FA2E86505690FDD682D974CA72A
keyserver pool.sks-keyservers.net
emit-version
default-recipient-self
fixed-list-mode
keyid-format 0xlong
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
use-agent
verify-options show-uid-validity
list-options show-uid-validity
sig-notation [email protected]=%g
cert-digest-algo SHA256

My .gnupg/gpg-agent.conf is:

default-cache-ttl 300
max-cache-ttl 999999
keep-display

and the output of gpg -K is:

sec   rsa4096/0x0FDD682D974CA72A 2011-10-01 [SC] [expires: 2021-02-01]
      3BB639E56F861FA2E86505690FDD682D974CA72A
uid                   [ultimate] Matt Turner <[email protected]>
uid                   [ultimate] Matt Turner <[email protected]>
uid                   [ultimate] Matt Turner <[email protected]>
uid                   [ultimate] Matt Turner <[email protected]>
ssb   rsa4096/0xB312ECDA6AEB12ED 2011-10-01 [E] [expires: 2021-02-01]
ssb>  ed25519/0x9C825A6605D40BBE 2018-07-24 [S] [expires: 2021-07-24]
ssb>  cv25519/0x51AB58039F74ED6B 2018-08-15 [E] [expires: 2021-08-14]

Thanks a bunch for taking a look. I really appreciate it.

mattst88 avatar Apr 21 '20 21:04 mattst88

Additionally, my ~/.password-store/.gpg-id is

0x51AB58039F74ED6B!
0xB312ECDA6AEB12ED!

mattst88 avatar Apr 21 '20 21:04 mattst88

Anything I can do to help?

mattst88 avatar Apr 29 '20 21:04 mattst88

@mattst88 Not at present. I've not yet managed to replicate the issue, but I haven't been able to spend much time on it yet either - have been very busy over the last few days dealing with C19-related stuff. I haven't forgotten about it.

erayd avatar Apr 29 '20 21:04 erayd