A few things to be wary of:

* KeePassHTTP doesn't use authenticated encryption for its protocol and thus is insecure (decrypt password level insecure). Please make sure you don't have this issue.

* Browser integration means there is only some JS code between my unlocked password vault and random websites. Please study findings from Tavis Ormandy and others who found such vulnerabilities in LastPass et al

Your second point is a great point, and I believe that there should be a user prompt every time something tries to read from the password database over any API.

With that said, what's the threat model for the first point? Is localhost interception a serious risk?

As far as I know, localhost can't be intercepted. Except for unintentional mistakes such as binding to 0.0.0.0 instead of 127.0.0.1. And inevitably there are going to be some tinkerers who'll run it over the network because it suits them.

keepassxc-browser uses libsodium's box method for encrypting the messages. Only public keys are transferred between the extension and KeePassXC. You still need a valid private keys and a nonce for decrypting and encrypting the replies. You can read a more detailed description from the github page.

I have been keeping eye on the vulnerabilities and going to be very careful when it is time for a final release. Currently if there's any vulnerabilities, these are almost identical to chromeIPass' possible vulnerabilities.

Well, yes, that's the goal. But it's surprisingly easy to mess up. I think the people here are cautioning you not to get overconfident, and to make sure you research the details of the flaws in other systems.

It is easy to mess up, yes. I'm not overconfident, but almost the opposite. Without being totally paranoid, I'm usually pretty certain something important is forgotten. All help is welcome :)

chromeIPass' possible vulnerabilities being?

KeePassXC restricts chromeIPass to localhost, so data should be safe. Still, chromeIPass exchanges encryption keys in base64. Basically that's plain text. These are the only keys used, so technically it's possible to steal those keys (if not localhost). But if someone has permission to read your loopback or local packet traffic, your info is gone..

Other than that, chromeIPass uses quite old libraries and depricated API functions. Those haven't been updated in ages. keepassxc-browser should fix all issues mentioned above :)

Also, any autofilling is disabled by default.

The official and latest version is always available here: https://github.com/varjolintu/keepassxc-browser

Firefox Nightly (version 56) is also supported. The extension will work officially when Mozilla releases build 57.

Have you considered dual browser extensions as in this paper:

https://arxiv.org/abs/1706.05085

>The prototype Horcrux client, implemented as a Firefox add-on, is split into two components, with code that has access to the user's master's password and any key material isolated into a small auditable component, separate from the complexity of managing the user interface.

Interesting idea. Gotta read the paper. Thank you.

Can I talk to you about an idea I have regarding automating authentication extensions? There's no email in your profile, I'm afraid.

Any chance of creating an Opera version as well? I just force installed the chrome version on Opera, but it doesn't seem to work.

I'll take look. If Opera supports webextensions, then it should be viable.

awesome will definitely signup to be a beta test when you get it where you want that.

actively using lastpass now and would like to move to an open source solution I feel like I can trust

You can go fully OSS already. Try https://github.com/pfn/passifox. It is using KeePassXC http protocol. I'am working on it's replacement.