It's free software; You have no right to complain or dictate priorities when you aren't paying for it. You aren't the customer, KeePass 2 advertisers are.
Use 1password and pay $5 a month if you want the right to complain.
Projects should not be exempt from criticism just because they're free. That's a terrible attitude. The article does not attempt to dictate anything, I would not even call it a complaint. It merely points out unsafe practices and recommends a solution, in a very objective tone.
That's a justifiable sentiment when people are complaining about missing features or mundane bugs, but security vulnerabilities are a whole different matter. That's causing harm, not just failing to provide value. You're still allowed to complain about a mugging you didn't pay for, after all.
Even if you believe there is no right to complain, you have the right to warn others about issues you see. Contacting the maintainer beforehand and suggesting a fix to them is common courtesy if you do that.
I'm not necessarily saying that Keepass2 provides a negative value overall. As you say, that's a subjective judgement. However, the unnecessary MitM exposure is certainly a negative value.
What "complaint" are you talking about? The blog is an objective explanation of a CVE along with explicit suggestions to the author and an discussion on how to protect yourself if you're a user.
It is not free software, it's proprietary. Please don't use the phrase "free software" in this context, as it confuses people. It has a very specific meaning in the context of software.
'Free' has exactly two specific meanings on the context of software. Sorry to burst your bubble. The version you are referring to is irrelevant in the minds of the vast majority of people who use software.
On the homepage it says: "KeePass is really free, and more than that: it is open source (OSI certified). You can have a look at its full source and check whether the encryption algorithms are implemented correctly.".
>You aren't the customer, KeePass 2 advertisers are.
Well certainly those advertisers will leave along with the user base. This sort of silly attitude is what keeps a lot of people from using free software to begin with.
The answers here are off the mark. You can obviously have the update channel use HTTPS and keep your website at HTTP (not recommended, but certainly possible).
The way the update system works (according to the article) is that it shows a pop-up with the new version, and that pop-up opens their site (via HTTP). It is conceivable that they'd rely on the impressions coming from update dialogs for their ad revenue, so the argument they used (which - just to clarify - is not my argument) would apply here as well. Switching to HTTPS (or some other signing mechanism) for the update check would solve one of the problems described in the article (tricking the user into thinking there's a new version available), but it would not eliminate the MitM opportunity on the site itself.
So wait, so this project that I use to store my passwords and that always seemed to take security and encryption seriously is leaving a public vulnerability unfixed because of "lost ad revenue"??
I'm baffled.
I completely understand the need to support the project financially, but this answer leaves me feeling very uncomfortable.
1. Many ad networks do not support serving over HTTPS.
2. Serving HTTP ads only your HTTPS-only site will show scary mixed-content warnings in many browsers, driving away users.
That's wild, I didn't expect any security-centric website in 2016 to be HTTP-only! The reasoning for not doing it is weird too, they could at the very least move the update logic over to a separate SSL endpoint.
Anyway, I'm not quite sure on the differences between them but I've been using KeePassX for years and recommend it thoroughly (as long as you're not looking for a easily synced or multi-user product): https://www.keepassx.org/
> That's wild, I didn't expect any security-centric website in 2016 to be HTTP-only!
Both of the websites for PuTTY (www.putty.org and www.chiark.greenend.org.uk) are also non-encrypted. At least the downloads are hosted on a third server (the.earth.li) which does use HTTPS and 2048-bit GPG signatures are provided.
putty.org is not owned by the PuTTY developers; after some arguments the two parties came to an agreement about the use of the domain name, but you should not trust putty.org.
The advantage is that you get to keep your passwords on a single database rather than having a separate copy of the database for each operating system. Synchronizing two separate copies of the database would be painful.
An alternate solution is to keep a single password database on a FAT32 formatted partition or thumbdrive which is readable from both Operating systems.
I have very complex password generation requirements for some of the services I need to access and KeePassX does not:
1) have nearly the same level of support for defining complex password generation rules
2) have support for saving said custom password generation as a profile
So, KeePass + wine it is until I have a better alternative. :)
Inertia. I've been using KeePass for years and I'm still on v1 because at the time the v1 database format was more well supported across all the "keepass" compatible apps on iOS, OS X, Android, etc.
What I have works for me very well although I will admit that the v2 database format is supported well enough these days that I could migrate.
Unfortunately, the package is just a mono-wrapped version of keepass2, and in my experience runs equally as bad, if not worse, than keepass2 under WINE.
Having used both for several months, I found the only workable option for myself was converting the database to KDB 1.x and using KeePassX.
Often enough that I don't want to have to rely on a separate script or service to generate the passwords for me and save the profiles and then copy the result into KeePass entries.
Why have you always been skeptical of KeePass? What is it about KeePassX that reassured you?
I looked at KeePassX several years ago but it didn't have as many security features as KeePass. For example, KeePass supports entering the password via secure desktop where KeePassX didn't.
KeePassX doesn't do auto-updating, for one. I am kind of a purist when it comes to software, and anything that feels clunky and bloated I'm just going to assume is made by people with insufficient competence. And truly, nobody is competent enough on their own, it requires a community. And it is much easier to collaborate through github than through... however it is that KeePass does it.
"Received response from Dominik Reichl: The vulnerability will not be fixed. The indirect costs of switching to HTTPS (like lost advertisement revenue) make it a inviable solution."
Well the indirect costs of not fixing it just got a lot bigger. Now a lot of people will realize that their passwords are not as safe as KeePass claims they are and will switch to a different product. So this way they loose both their money and their users' trust. Not a very good business decision.
That response is crazy. If he's so set at keeping the homepage http, then make a download.keypass.com site and keep the downloads on there, with https required.
Eh. Still vulnerable to HSTS attack. To me HTTPS without HSTS is only protection to programmers. To the public, HTTPS without HSTS protection is essentially useless against MITM attacks.
That's if they switch the entire site to https. They could just switch the update check to https and have no problems with ads (although it would be admittedly less secure).
> Now a lot of people will realize that their passwords are not as safe as KeePass claims they are and will switch to a different product.
Not really.
Just check the package you download is signed by the developer and you're safe. Authenticode signatures are present on all KeePass releases on Windows and most Linux users probably get it from a distro package manager anyways.
Roboform has been my go to, but honestly I don't know how well the security is on it but by the track record it looks as though they have not had any issues by what short searching I have done.
I've seen several open source systems that share on GitHub such as PadLock but have yet to be able to test these to compare to Roboform. Considering how cheap I was able to pick up Roboform to (as a college student I got 4 years for 1) I really haven't seen the urge to switch considering on how universal Siber System's Roboform does on multiple systems.
Even though this can also be a downfall if the developer's slack on one system, I have been satisfied with these guys since I started using them so many years ago and really haven't found many complaints.
edit My entire reasoning for posting was that while I'm very familiar with Roboform my experience with KeePass was always lacking compared to others.
Is this becuase all the third party assets and scripts would need to be HTTPS as well? If they weren't then you get that browser warning about mixed content?
Why is there advertisement on the automated update server? Why can't he just split them apart? What with things like Let's Encrypt nowadays, there really shouldn't be any excuse not to use https. Especially for a security related product!
There isn't an automated update server. KeePass can't auto-update. The web server has a text file on it that contains the version number of the latest release. KeePass (optionally) checks that file to see if a new version is available and displays a notification to the user. Downloads and installation of new versions has to be done manually by the user. The binaries are hosted on SourceForge and other mirror sites, and in my cursory checking those are serving the file over HTTPS. The binaries are digitally signed.
So any possible attack against KeePass would as most cause the notification dialog to appear saying there's a new version.
anyway, the author found a solution by signing the text file that the update checker looks at. IMO, that's a superior solution to HTTPS. He's posted a statement on the KeePass website. http://keepass.info/help/kb/sec_issues.html#updsig
I just use a gpg-encrypted org-mode file (I can transparently decrypt it with emacs). It's remarkably convenient, and I don't have to worry about software going out of support.
Couldn't this be solved by signing the update file?
But the excuse of the dev is bogus in any case. In is trivial to have that single file transferred via HTTPS. His ad revenue excuse makes me thing something fishy is going on here.
Many years ago I reported two bugs in KeePass, one related to the tray icon, and the other related to some bad rendering in the GUI.
Both were closed, with reasons like "this is a bug in .NET", "this is a bug in Windows". Maybe they were, but somehow other applications didn't expose them. The bugs were annoying, and if it were my software I would have fixed them somehow, even if they were not my fault.
Long story short, the author gave me a bad impression, the kind of "know it all, know it best" attitude. So his refusal to fix this MITM problem doesn't surprise me one bit.
77 comments
[ 4.8 ms ] story [ 148 ms ] threadUse 1password and pay $5 a month if you want the right to complain.
Updates themselves are signed packages. While it's not ideal, careful users do gain value in an open, free, and mature solution.
Full disclosure: I sell a plugin for KeePass 2.
It is not free software, it's proprietary. Please don't use the phrase "free software" in this context, as it confuses people. It has a very specific meaning in the context of software.
In the context of software it can also mean FOSS, but just because we're talking about software doesn't mean we suddenly lose the 'no cost' meaning.
Why do you say it's proprietary?
Well certainly those advertisers will leave along with the user base. This sort of silly attitude is what keeps a lot of people from using free software to begin with.
Or just sign the updates and version information.
I'm baffled.
I completely understand the need to support the project financially, but this answer leaves me feeling very uncomfortable.
Anyway, I'm not quite sure on the differences between them but I've been using KeePassX for years and recommend it thoroughly (as long as you're not looking for a easily synced or multi-user product): https://www.keepassx.org/
Both of the websites for PuTTY (www.putty.org and www.chiark.greenend.org.uk) are also non-encrypted. At least the downloads are hosted on a third server (the.earth.li) which does use HTTPS and 2048-bit GPG signatures are provided.
Unfortunately there is no KeePassHttp support yet, so you can't hook it up to your browser, but there is a fork available with full support.
https://github.com/droidmonkey/keepassx_http/
An alternate solution is to keep a single password database on a FAT32 formatted partition or thumbdrive which is readable from both Operating systems.
http://packages.ubuntu.com/xenial/keepass2
What I have works for me very well although I will admit that the v2 database format is supported well enough these days that I could migrate.
Having used both for several months, I found the only workable option for myself was converting the database to KDB 1.x and using KeePassX.
I looked at KeePassX several years ago but it didn't have as many security features as KeePass. For example, KeePass supports entering the password via secure desktop where KeePassX didn't.
Well the indirect costs of not fixing it just got a lot bigger. Now a lot of people will realize that their passwords are not as safe as KeePass claims they are and will switch to a different product. So this way they loose both their money and their users' trust. Not a very good business decision.
Not really.
Just check the package you download is signed by the developer and you're safe. Authenticode signatures are present on all KeePass releases on Windows and most Linux users probably get it from a distro package manager anyways.
I've seen several open source systems that share on GitHub such as PadLock but have yet to be able to test these to compare to Roboform. Considering how cheap I was able to pick up Roboform to (as a college student I got 4 years for 1) I really haven't seen the urge to switch considering on how universal Siber System's Roboform does on multiple systems.
Even though this can also be a downfall if the developer's slack on one system, I have been satisfied with these guys since I started using them so many years ago and really haven't found many complaints.
edit My entire reasoning for posting was that while I'm very familiar with Roboform my experience with KeePass was always lacking compared to others.
This doesn't entirely make sense. I'm sure it's possible to serve adverts on a HTTPS page, and let's encrypt is hardly expensive
Yes, you can, but you lose a tremendous amount of ad revenue and a number of ad providers still don't support HTTPS.
Too many ad buyers don't have https support, so the number of bidders for the ad space is lower, meaning a lower price per ad.
So any possible attack against KeePass would as most cause the notification dialog to appear saying there's a new version.
anyway, the author found a solution by signing the text file that the update checker looks at. IMO, that's a superior solution to HTTPS. He's posted a statement on the KeePass website. http://keepass.info/help/kb/sec_issues.html#updsig
Anyone know any good password managers that have web login and support U2F? Lastpass does not :(
But the excuse of the dev is bogus in any case. In is trivial to have that single file transferred via HTTPS. His ad revenue excuse makes me thing something fishy is going on here.
Both were closed, with reasons like "this is a bug in .NET", "this is a bug in Windows". Maybe they were, but somehow other applications didn't expose them. The bugs were annoying, and if it were my software I would have fixed them somehow, even if they were not my fault.
Long story short, the author gave me a bad impression, the kind of "know it all, know it best" attitude. So his refusal to fix this MITM problem doesn't surprise me one bit.
https://sourceforge.net/p/keepass/discussion/329220/thread/a...