SoylentNews is people
SoylentNews
An engadget story has the following to say about KeePass2 and developer Dominik Reichl:
Think it's bad when companies take their time fixing security vulnerabilities? Imagine what happens when they avoid fixing those holes in the name of a little cash. KeePass 2 developer Dominik Reichl has declined to patch a flaw in the password manager's update check as the "indirect costs" of the upgrade (which would encrypt web traffic) are too high -- namely, it'd lose ad revenue. Yes, the implication is that profit is more important than protecting users.
This discussion has been archived.
No new comments can be posted.
Password App Developer Overlooks Security Hole to Preserve Ads
|
Log In/Create an Account
| Top
| 47 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
No animal should ever jump on the dining room furniture unless
absolutely certain he can hold his own in conversation.
-- Fran Lebowitz
(Score: 5, Informative) by Anonymous Coward on Monday June 06 2016, @02:57PM
This is a tempest in a teapot and is being exaggerated by Engadget. Keepass does not have an auto-update feature. The Keepass program checks the web site to see if a new version is available. If there is a new version the program displays a notification to the end user. That's it. Full stop.
The author has fixed the problem by using a digital signature to sign the update text file on the web site that the Keepass program looks for.
There's a detailed response from the author here: http://keepass.info/help/kb/sec_issues.html#updsig [keepass.info]
As for ad revenue, many ad networks still do not support HTTPS. This creates a problem where there are more people willing to pay for ads that show up on HTTP ad networks than HTTPS. Because of fewer impressions on HTTPS the ads are worth less too. There's a post on Hacker News where one guy saw a 30% drop in ad revenue when he switched his site to HTTPS. https://news.ycombinator.com/item?id=11803716 [ycombinator.com]
(Score: 0) by Anonymous Coward on Monday June 06 2016, @03:27PM
However intercepting the unencrypted connection could result in users not being informed about a critical update. And the fact that they normally would be informed means they'd probably not check the web site by themselves. Admittedly that's a much lower security issue than an unprotected update mechanism, but it's a security issue nonetheless.
(Score: 0) by Anonymous Coward on Monday June 06 2016, @03:49PM
I agree that there could still be a minor problem caused by it. Your example was great.
That's also why I said that this is a tempest in a teapot. Many of the articles that I've seen about this in the last 24 hours are misrepresenting the facts. Stories are being sensational and inventing facts, talking about keepass downloading and installing updates (which it can't do) via HTTP and saying that users could get infected with malware.
The problem and its severity and impact are being blown way out of proportion. As a keepass user it irritates me because I see a free software developer getting shit on by the tech media in order to manufacture outrage and get their articles more views (i.e., more ad revenue).
(Score: 2) by theluggage on Monday June 06 2016, @05:57PM
However intercepting the unencrypted connection could result in users not being informed about a critical update
Read the G.P post: the update.txt file is now digitally signed. Your method wouldn't work: even if the author's site has been pwn3d (which HTTPS is powerless to prevent) then the bad guys won't be able to sign the file. That solution is actually superior to using HTTPS.
Oh, and remember: installing that critical update will invalidate the 6-week source code audit you performed on the current version before entrusting the launch codes for your personal nuclear arsenal to it.
Seriously: even if your method worked it would be a minuscule risk: some weighing of risks in context is required. The biggest risk comes from pushing every update as critical and urgent and ignoring the real possibility of the update failing or introducing a regression.
(Score: 0) by Anonymous Coward on Tuesday June 07 2016, @12:28PM
That doesn't help against serving an outdated version of that file, complete with its valid signature.
(Score: 2) by theluggage on Tuesday June 07 2016, @01:54PM
That doesn't help against serving an outdated version of that file, complete with its valid signature.
So give the file an expiry date & renew it regularly. Oh, and if a security patch is so desperately critical that it is worth someone going to great effort to suppress it, don't rely on an optional automatic update notification as the sole means of publicising it.
There comes a point at which encryption becomes equivalent to putting a steel door on a tent. HTTPS is firmly in that category, because it is only as strong as the infrastructure for issuing certificates - and that is weak by design because it has to allow users to visit sites without manually installing/verifying certificates.
(Score: 0) by Anonymous Coward on Monday June 06 2016, @04:52PM
HTTPS does defend against some attacks, but criminals who can compromise the Certificate Authority system have much of the same ability to conduct man-in-the-middle attacks and compromise data. Blindly pushing HTTPS while leaving unresolved flaws in place such as major browser vendors crapping all over themselves when they see a self-signed (and thus invulnerable to upstream CA issues) certificate promotes a false sense of security.
The cryptographic signatures for the downloads are provided by the author, and those are mathematically impervious to manipulation via weaknesses in HTTP or HTTPS. The lesson here is not to bash the software's author or website maintainer, but to cryptographically verify the integrity of the software you use so that the NSA can't send a National Security Letter to Verisign and get their own special NSAkey which will be used to show you a happy little lock icon while the data stream's integrity has been totally destroyed.