Stories
Slash Boxes
Comments

SoylentNews is people

Password App Developer Overlooks Security Hole to Preserve Ads

posted by cmn32480 on Monday June 06 2016, @02:22PM   Printer-friendly
from the they-gotta-be-kidding dept.

Fnord666 writes:

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.

Original Submission

 
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
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by zocalo on Monday June 06 2016, @06:52PM

    by zocalo (302) on Monday June 06 2016, @06:52PM (#356048)

    What makes you think that attackers with the ability to replace binaries are clueless enough to forget to update the checksums?

    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!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by jimshatt on Monday June 06 2016, @07:43PM

    by jimshatt (978) on Monday June 06 2016, @07:43PM (#356070) Journal
    You don't have to generate identical checksums. You just have to hijack the page displaying the checksums as well (usually on the same page, which makes it even easier).

    • (Score: 2) by zocalo on Monday June 06 2016, @08:33PM

      by zocalo (302) on Monday June 06 2016, @08:33PM (#356094)
      Which would be why I mentioned having the checksums on multiple independant sites.
      --
      UNIX? They're not even circumcised! Savages!

      • (Score: 0) by Anonymous Coward on Monday June 06 2016, @09:59PM

        by Anonymous Coward on Monday June 06 2016, @09:59PM (#356140)

        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

          by zocalo (302) on Tuesday June 07 2016, @08:07AM (#356322)
          Um, what? You do realise I'm just describing a mechanism that has been used by Linux distributions and many other things to verify download integrity without any major incidents not caused by human failings for decades, right?
          --
          UNIX? They're not even circumcised! Savages!