The indirect costs of switching to HTTPS (like lost advertisement revenue) make it a inviable solution. How does HTTPS result in lost ad revenue?
MitM Attack against KeePass 2’s Update Check
11–20 of 78 posts
Re: MitM Attack against KeePass 2’s Update Check
#12The indirect costs of switching to HTTPS (like lost advertisement revenue) make it a inviable solution. How does HTTPS result in lost ad revenue?
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).
Or just sign the updates and version information.
Re: MitM Attack against KeePass 2’s Update Check
#13I was always skeptical of KeePass which is why I've been using KeePassX. It is just a simple Qt app. 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/
I'd probably switch to KeePassX instead of running KeePass in wine if the password generator were as flexible.
Re: MitM Attack against KeePass 2’s Update Check
#14Roboform 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.
Re: MitM Attack against KeePass 2’s Update Check
#15The indirect costs of switching to HTTPS (like lost advertisement revenue) make it a inviable solution. How does HTTPS result in lost ad revenue?
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). Or just sign the updates and version information.
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.
Re: MitM Attack against KeePass 2’s Update Check
#16It'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.
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.
Re: MitM Attack against KeePass 2’s Update Check
#17"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 mon…
Right. This is a security product. Any security product that makes things worse (and there are all too many of them) has no right to exist.
Re: MitM Attack against KeePass 2’s Update Check
#18"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 mon…
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.
Re: MitM Attack against KeePass 2’s Update Check
#19The indirect costs of switching to HTTPS (like lost advertisement revenue) make it a inviable solution. How does HTTPS result in lost ad revenue?
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.
Re: MitM Attack against KeePass 2’s Update Check
#20It'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.
Giving something away for free is not an excuse for it to provide negative value by exposing its users to MitM attacks.