5 ms·

> Downloads page: http://keepass.info/download.html I still see a glaring MitM vulnerability… Until the author actually switches to HTTPS, network operators c

by Sephr 10y ago

> Downloads page: http://keepass.info/download.html I still see a glaring MitM vulnerability… Until the author actually switches to HTTPS, network operators can simply hijack the original downloads page in the first place. This update is barely a mitigation. If he wants more ad revenue, his only option is to find another ad network. Eventually someone else is going to start hosting a popular fork on a different HTTPS site if he keeps stubbornly ignoring this issue.

0942v8653 10y ago
If it's cryptographically signed and you found the public key from a more reputable place, you are ok. This is how apt repositories work - they use HTTP, but since everything is signed, mitm attacks can't do much other than see which packages you install.
- Sephr 10y ago
  Almost nobody is going to search for external sources to verify the content on keepass.info > mitm attacks can't do much other than see which packages you install On the contrary, if you MitM the entire downloads page you can simply offer up a hacked/backdoored version of the software. There is no signature check if you remove the signature check in the version that you distribute.
  - mseebach 10y ago
    That's the fundamental trust-bootstrapping problem. You need an independent way to establish trust in the first interaction. In SSL, it's the (very flawed) CA model (never mind that nothing about SSL protects you if the website content is compromised). In this case, you can verify the download file signatures on keybase.io which is probably significantly safer than the CA model is. Sure, in this day and age, it's slightly disconcerting to see a security-related website that isn't SSL, but on the other hand, the tendency to blindly trust the green padlock is probably even more dangerous. http://keepass.info/integrity_sig.html http://keepass.info/integrity_sig.html https://keybase.io/reichl https://keybase.io/reichl
    - tekklloneer 10y ago
      I don't really see how this is relevant. It may be flawed, but clowning the CA model is beyond the abilities of the vast majority of attackers.
      - mseebach 10y ago
        Setting up a MITM attack is not exactly trivial, either.
    - ygjb-dupe 10y ago
      Uh, sure. But TBH, if I am going to go through the trouble of MITM'ing the site, then I am going to rewrite the site to: * include my awesome fingerprint * link to my awesome key * link to my l33t entry on keybase Side note - the CA model has issues, but in what world is pointing users to a VC funded startup that has only been around for two years "safer" than the flawed, but well understood security model of the CA system? I don't mean to impugn Keybase, from watching them I like what they are doing, but bootstrapping trust based on content they control is hardly ideal, and I would be shocked to hear someone say that Keybase is more reliable or more trustworthy than the CA/Browser Forum (10 years old) and the browser vendors (>20 years old depending on vendor/code base).
Nutomic 10y ago
That fork is KeePassX [1]. And it's cross-platform too! [1] https://www.keepassx.org/ https://www.keepassx.org/
- Sephr 10y ago
  Oh, I see that KeePassX now supports the KeePass2 format now! I'll definitely give it a try now that it supports that. Support for the KeePass2 format was the only thing preventing me from using it in the past.
  - 0xfeba 10y ago
    Ah finally! The Mono version is wonky.
- drdaeman 10y ago
  Sadly, there is no sync and syncing offline changes is non-trivial in KeePass. (At the very least, a .kdbx on Syncthing/Droxbox-like storage WILL eventually lead to data loss.)
  - discreditable 10y ago
    > At the very least, a .kdbx on Syncthing/Droxbox-like storage WILL eventually lead to data loss. It's been working for me without issue since 2009-ish. I've used 1.x and 2.x databases in Dropbox.
  - distances 10y ago
    At some point new passwords will be added quite rarely. Clash can happen, but in practice I've been happily using this method now for years and years.
  - mgreenly 10y ago
    I concur with the other commenters... I've been syncing with dropbox for years now and never had a conflict. I guess it helps I tend not to leave it open/running on multiple machines. Open it, use it, close it.

by Sephr 10y ago

0942v8653 10y ago

If it's cryptographically signed and you found the public key from a more reputable place, you are ok. This is how apt repositories work - they use HTTP, but since everything is signed, mitm attacks can't do much other than see which packages you install.

Sephr 10y ago
Almost nobody is going to search for external sources to verify the content on keepass.info > mitm attacks can't do much other than see which packages you install On the contrary, if you MitM the entire downloads page you can simply offer up a hacked/backdoored version of the software. There is no signature check if you remove the signature check in the version that you distribute.
- mseebach 10y ago
  That's the fundamental trust-bootstrapping problem. You need an independent way to establish trust in the first interaction. In SSL, it's the (very flawed) CA model (never mind that nothing about SSL protects you if the website content is compromised). In this case, you can verify the download file signatures on keybase.io which is probably significantly safer than the CA model is. Sure, in this day and age, it's slightly disconcerting to see a security-related website that isn't SSL, but on the other hand, the tendency to blindly trust the green padlock is probably even more dangerous. http://keepass.info/integrity_sig.html http://keepass.info/integrity_sig.html https://keybase.io/reichl https://keybase.io/reichl
  - tekklloneer 10y ago
    I don't really see how this is relevant. It may be flawed, but clowning the CA model is beyond the abilities of the vast majority of attackers.
    - mseebach 10y ago
      Setting up a MITM attack is not exactly trivial, either.
  - ygjb-dupe 10y ago
    Uh, sure. But TBH, if I am going to go through the trouble of MITM'ing the site, then I am going to rewrite the site to: * include my awesome fingerprint * link to my awesome key * link to my l33t entry on keybase Side note - the CA model has issues, but in what world is pointing users to a VC funded startup that has only been around for two years "safer" than the flawed, but well understood security model of the CA system? I don't mean to impugn Keybase, from watching them I like what they are doing, but bootstrapping trust based on content they control is hardly ideal, and I would be shocked to hear someone say that Keybase is more reliable or more trustworthy than the CA/Browser Forum (10 years old) and the browser vendors (>20 years old depending on vendor/code base).

Nutomic 10y ago

That fork is KeePassX [1]. And it's cross-platform too! [1] https://www.keepassx.org/ https://www.keepassx.org/

Sephr 10y ago
Oh, I see that KeePassX now supports the KeePass2 format now! I'll definitely give it a try now that it supports that. Support for the KeePass2 format was the only thing preventing me from using it in the past.
- 0xfeba 10y ago
  Ah finally! The Mono version is wonky.
drdaeman 10y ago
Sadly, there is no sync and syncing offline changes is non-trivial in KeePass. (At the very least, a .kdbx on Syncthing/Droxbox-like storage WILL eventually lead to data loss.)
- discreditable 10y ago
  > At the very least, a .kdbx on Syncthing/Droxbox-like storage WILL eventually lead to data loss. It's been working for me without issue since 2009-ish. I've used 1.x and 2.x databases in Dropbox.
- distances 10y ago
  At some point new passwords will be added quite rarely. Clash can happen, but in practice I've been happily using this method now for years and years.
- mgreenly 10y ago
  I concur with the other commenters... I've been syncing with dropbox for years now and never had a conflict. I guess it helps I tend not to leave it open/running on multiple machines. Open it, use it, close it.