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.
(Score: 4, Insightful) by TrumpetPower! on Monday June 06 2016, @05:53PM
What makes you think that attackers with the ability to replace binaries are clueless enough to forget to update the checksums?
If you can't trust the server to serve up what you expect it to serve, all bets are off -- especially including your rather naïve bet that you can trust the server to pass you subtle hints that only initiates such as you are able to interpret.
Or, as has been said for ages: in for a penny, in for a pound.
There's no good solution. The PGP "Web of Trust" model was a good one, such that it wasn't all that difficult to attain overwhelming (though still imperfect) confidence.
In practice, today...well, you pretty much have no choice but to trust your OS provider on these sorts of things. OS X comes with a darned good password manager, Keychain, that you can trust as much as the OS itself -- however much that might be. If your OS (such as Windows) doesn't come with one, then you've got to decide which third party (including yourself) you might trust. That sort of decision comes with an analysis of what's at stake and what the risks are...and that's something that you can only ultimately decide for yourself.
Cheers,
b&
All but God can prove this sentence true.
(Score: 2) by zocalo on Monday June 06 2016, @06:52PM
In the specific case of checksumming? Maths. An attacker might (just) be able to generate an identical checksum on a malicious version of a file using a single checksum algorithm, especially for something known to be flawed like MD5, but if the original file is checksummed using two different methods - even if it's just MD5 & SHA1 - then creating that dual collision *on the same file* is almost certainly going to be mathematically impossible. There's no subtle hints about it; the whole point of publishing and advertising the checksums in multiple locations (the original site, Facebook page, SourceForge, etc.) is to provide that assurance through the knowledge that a would be attacker would have needed to compromise multiple sites at the same time; again, not impossible, but exceedingly unlikely.
As you said, the decision on trust comes with an analysis of what's at stake and what the risks are. My point was that when you are putting a lot of eggs into a single basket, which is certainly the case with a password manager, then you probably want to raise the bar a bit on what the stakes are and act accordingly.
UNIX? They're not even circumcised! Savages!
(Score: 2) by jimshatt on Monday June 06 2016, @07:43PM
(Score: 2) by zocalo on Monday June 06 2016, @08:33PM
UNIX? They're not even circumcised! Savages!
(Score: 0) by Anonymous Coward on Monday June 06 2016, @09:59PM
Then an attacker would only have to fake authorization to the white pages, just like vuze. Your idea is impractical.
(Score: 2) by zocalo on Tuesday June 07 2016, @08:07AM
UNIX? They're not even circumcised! Savages!