6 ms·

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

by Quiark 9y ago

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

varjolintu 9y ago
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.
- sillysaurus3 9y ago
  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.
  - varjolintu 9y ago
    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 :)
- gaia 9y ago
  chromeIPass' possible vulnerabilities being?
  - varjolintu 9y ago
    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 :)
  - varjolintu 9y ago
    Also, any autofilling is disabled by default.
jsfitzsimmons 9y ago
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?
- Quiark 9y ago
  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.

by Quiark 9y ago

varjolintu 9y ago

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.

sillysaurus3 9y ago
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.
- varjolintu 9y ago
  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 :)
gaia 9y ago
chromeIPass' possible vulnerabilities being?
- varjolintu 9y ago
  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 :)
- varjolintu 9y ago
  Also, any autofilling is disabled by default.

jsfitzsimmons 9y ago

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?

Quiark 9y ago
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.