Publish and commit to security goals

[FiloSottile]

The reason I would personally use an extension instead of -c is that it can extract the hostname securely, blocking phishing attempts. The reason I would personally use this instead of, say, LastPass is that there would be no way for the page to trigger autocomplete (and exploit potential host-matching vulnerabilities) without user input and confirmation.

These are however only my speculations on the security goals of the extension. I could audit it myself, but I would have to worry about functionality changing later as there is no commitment. Also, that would make clear what is and what isn't a security vulnerability.

Essentially, what's your threat model? (I know it's cliche.)

(Thanks for the work! ✨)

[maximbaz]

Hey @FiloSottile,

This is an interesting question you are asking. The project is essentially being driven by community, there are no "official" security goals, and my personal reasons to use browserpass are very much the same as yours.

I would certainly invite you to audit the project and start the discussion on what you believe should be the security goals. Anyone interested is welcome to share the feedback, and I would definitely do so.

What I can offer once we have some kind of a shared agreement on the security goals is the following: if I see a feature request or a pull request that breaches the current agreement, I'll give my best to question this change and I'll ping you and others who were active in this thread with a grace period of say 1 week before merging the change.

[qbit]

One of my goals is to make browserpass use golang.org/x/crypto/openpgp, this would let us remove at least exec from the pledge(2) call. The pledge part is entirely specific to OpenBSD - but not having to call exec.Command seems like it would benefit everyone!

[maximbaz]

I've seen such suggestion before, and an argument against this. That being said, I don't know if that claim is actually true, and I'm fine with trying to make use of openpgp as long as I can still use my Yubikey 🙂

[qbit]

I use a yubikey too - definitely looks like using x/crypto/openpgp won't work for now.

[FiloSottile]

I gave it a try in #153. To be clear, I did not audit the codebase to check that these hold true, but they seem to be a sane set of goals.

Unfortunately, golang.org/x/crypto/openpgp can't indeed use a gpg agent, so is incompatible with smartcards and probably not an option.

[qbit]

Just found this: https://godoc.org/go.mozilla.org/gopgagent - I will try to put together a test to see if I can use Go / gpg-agent and smartcards!

[FiloSottile]

AFAICT that does not implement any encryption commands.

[qbit]

Wouldn't it use the OpenPGP lib to do the encryption stuff? (similar to this: https://github.com/mozilla/sops/blob/master/pgp/keysource.go#L120)

[FiloSottile]

I don't think either gopgagent or x/crypto/openpgp support using the agent to have private key operations done, for example by a YubiKey. (I might be mistaken.)

[maximbaz]

@qbit I definitely encourage you to try it and come back with some results, positive or negative, awesome finding!