5 ms·

In retrospect, this seems like an obvious flaw in using third party clients for password management. The fact that KeePass is OSS is great, but it leads you to

by quenix 3y ago

In retrospect, this seems like an obvious flaw in using third party clients for password management. The fact that KeePass is OSS is great, but it leads you to have to rely on these shady pieces of software to access your vault on non-officially supported platforms like iOS. You wouldn’t have this problem if you used e.g. 1Password or Bitwarden. They have official iOS clients made by the same entity which you’ve already trusted with your secrets. tl;dr Having to trust a third party KeePass client isn’t very smart and forces you to trust two (2) entities instead of one with your secrets. This is such a deal breaker that it might turn one off accessing their KeePass vault on iOS at all.

artjomb 3y ago
Exactly, as a user you need to be aware of this addition of risk. Anonymous OSS maintainers are the issue here. When I want to use a project and want to reduce the risk here, I need to vet the maintainers in a similar way I would vet a company I want to invest in.
- bobmaxup 3y ago
  I don't think there is a need to have someone's reputation score to use their software. There are plenty of pieces of open source software running on operating systems that were contributed by people who are effectively anonymous. Also, it doesn't seem like a contributor's overall character would be a great measure of how malicious their contriubtions are, as evidenced by plenty of examples of assumed good people eventually doing bad things.
  - kjreact 3y ago
    I don’t understand why people believe that open source inherently makes software secure and trustable. Yes, you have access to look through the code, but I usually don’t have the expertise to understand what I’m looking at. I wouldn’t know how to look for well hidden exploits or malicious intent. I’m still reliant on others to find these issues. At the moment, I do rely on reputation before I trust open source software. But in the case of an app store, I can trust the reputation of the store. I can trust that the app store has to work to uphold their reputation which is their motivation for maintaining a good track record of identifying problem apps. I agree this is far from perfect, but I think it’s much safer than relying on open source. I love the idea of open source and I hope that it will never be replaced by app stores, but I don’t feel that software is inherently more trustworthy if it’s open source.
    - SAI_Peregrinus 3y ago
      I like to distinguish "trustworthy" from "trustable". Trustworthy software is worthy of trust: it is not malicious or unacceptably buggy. Trustable software is software which can, in theory, be verified to be trustworthy. OSS is trustable, but not necessarily trustworthy. Closed-source software might be trustworthy, but it's not trustable (since trustworthiness can't be verified).
      - kjreact 3y ago
        I believe it’s not necessary to fully verify a piece of software before it can be trusted. We humans are all black boxes, no one can read our minds, but we can trust each other through our reputations. I treat software the same way; as long as software comes from a reputable developer, I’ll give it the benefit of the doubt until proven otherwise. Verified trustworthy is too high a standard to hold to software. Take for example Log4j, an open source logging library used by many enterprise Java apps worldwide, had a huge vulnerability existing in its code base for over 7 years. Even with its widespread use and open sourced code, the exploit was not reported in a timely fashion. Thus I’m left with reputation as the only practical means of determining trust; imperfect as it may be.
    - o1y32 3y ago
      Exactly, in fact the reddit post talks about this situation -- the code that sents sensitive information is right there on GitHub but nobody saw it before OP did. And what could happen is that the developers maintains two codebases, one "clean" version on github and a "dirty" version that is almost identical except the part where it secretly sends your password, and use that version to build an iOS app. How would you ever know that?
TheDong 3y ago
I mean, if you use 1Password on both linux and iOS, you now trust both the mobile and desktop teams at 1password. You trust two separate supply chains, one for the iOS app dependencies, one for the linux dependencies. If you use bitwarden, you now trust the "bitwarden/mobile" and the "bitwarden/clients" repositories. Both of those programs _also_ have separate applications with separate code for mobile and desktop, so for those you _also_ have to audit twice the code (well, not that you can audit 1password's code). Anyway, if you're using any of these programs on desktop, you have to trust 100% of the programs you run as the same user as your password store client to not be reading memory to nab your database, so it's not like trusting one more program is that big a deal. I'm not even sure if I'm being sarcastic or not.
- ec109685 3y ago
  Two programs running under same user can’t by default read each other’s memory.
  - TheDong 3y ago
    > Two programs running under same user can’t by default read each other’s memory. 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user, and that sure lets me read all memory. I think /proc/$pid/mem works fine too, right? 'ReadProcessMemory' works fine as an unprivileged user on windows I _thought_, at least I know it did last time I used it. That was years ago. No clue about macOS. I assume most people on hacker news are using linux though, so that's the one that's relevant.
    - rootusrootus 3y ago
      > I assume most people on hacker news are using linux though, so that's the one that's relevant. I'd wager a beer that MacOS is the dominant OS. Followed by Windows. Followed by Linux.
    - natrys 3y ago
      > 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user I believe this requires `kernel.yama.ptrace_scope` to be set to 0, which is not the default in most distros? Or gdb to be granted specific capability, which I don't think is done by default either.

by quenix 3y ago

artjomb 3y ago

Exactly, as a user you need to be aware of this addition of risk. Anonymous OSS maintainers are the issue here. When I want to use a project and want to reduce the risk here, I need to vet the maintainers in a similar way I would vet a company I want to invest in.

bobmaxup 3y ago
I don't think there is a need to have someone's reputation score to use their software. There are plenty of pieces of open source software running on operating systems that were contributed by people who are effectively anonymous. Also, it doesn't seem like a contributor's overall character would be a great measure of how malicious their contriubtions are, as evidenced by plenty of examples of assumed good people eventually doing bad things.
- kjreact 3y ago
  I don’t understand why people believe that open source inherently makes software secure and trustable. Yes, you have access to look through the code, but I usually don’t have the expertise to understand what I’m looking at. I wouldn’t know how to look for well hidden exploits or malicious intent. I’m still reliant on others to find these issues. At the moment, I do rely on reputation before I trust open source software. But in the case of an app store, I can trust the reputation of the store. I can trust that the app store has to work to uphold their reputation which is their motivation for maintaining a good track record of identifying problem apps. I agree this is far from perfect, but I think it’s much safer than relying on open source. I love the idea of open source and I hope that it will never be replaced by app stores, but I don’t feel that software is inherently more trustworthy if it’s open source.
  - SAI_Peregrinus 3y ago
    I like to distinguish "trustworthy" from "trustable". Trustworthy software is worthy of trust: it is not malicious or unacceptably buggy. Trustable software is software which can, in theory, be verified to be trustworthy. OSS is trustable, but not necessarily trustworthy. Closed-source software might be trustworthy, but it's not trustable (since trustworthiness can't be verified).
    - kjreact 3y ago
      I believe it’s not necessary to fully verify a piece of software before it can be trusted. We humans are all black boxes, no one can read our minds, but we can trust each other through our reputations. I treat software the same way; as long as software comes from a reputable developer, I’ll give it the benefit of the doubt until proven otherwise. Verified trustworthy is too high a standard to hold to software. Take for example Log4j, an open source logging library used by many enterprise Java apps worldwide, had a huge vulnerability existing in its code base for over 7 years. Even with its widespread use and open sourced code, the exploit was not reported in a timely fashion. Thus I’m left with reputation as the only practical means of determining trust; imperfect as it may be.
  - o1y32 3y ago
    Exactly, in fact the reddit post talks about this situation -- the code that sents sensitive information is right there on GitHub but nobody saw it before OP did. And what could happen is that the developers maintains two codebases, one "clean" version on github and a "dirty" version that is almost identical except the part where it secretly sends your password, and use that version to build an iOS app. How would you ever know that?

TheDong 3y ago

I mean, if you use 1Password on both linux and iOS, you now trust both the mobile and desktop teams at 1password. You trust two separate supply chains, one for the iOS app dependencies, one for the linux dependencies. If you use bitwarden, you now trust the "bitwarden/mobile" and the "bitwarden/clients" repositories. Both of those programs _also_ have separate applications with separate code for mobile and desktop, so for those you _also_ have to audit twice the code (well, not that you can audit 1password's code). Anyway, if you're using any of these programs on desktop, you have to trust 100% of the programs you run as the same user as your password store client to not be reading memory to nab your database, so it's not like trusting one more program is that big a deal. I'm not even sure if I'm being sarcastic or not.

ec109685 3y ago
Two programs running under same user can’t by default read each other’s memory.
- TheDong 3y ago
  > Two programs running under same user can’t by default read each other’s memory. 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user, and that sure lets me read all memory. I think /proc/$pid/mem works fine too, right? 'ReadProcessMemory' works fine as an unprivileged user on windows I _thought_, at least I know it did last time I used it. That was years ago. No clue about macOS. I assume most people on hacker news are using linux though, so that's the one that's relevant.
  - rootusrootus 3y ago
    > I assume most people on hacker news are using linux though, so that's the one that's relevant. I'd wager a beer that MacOS is the dominant OS. Followed by Windows. Followed by Linux.
  - natrys 3y ago
    > 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user I believe this requires `kernel.yama.ptrace_scope` to be set to 0, which is not the default in most distros? Or gdb to be granted specific capability, which I don't think is done by default either.