4 ms·

Why would I use this vs something like KeePass/KeeFox? I was hoping to see a new cross-platform Qt/QML password manager with Firefox and Chrome integration plug

Why would I use this vs something like KeePass/KeeFox? I was hoping to see a new cross-platform Qt/QML password manager with Firefox and Chrome integration plugins.

thomnottom 10y ago
The main knock against KeePass for teams is that it's all or nothing. We've had to create multiple databases for different job functions, which becomes a pain to maintain. Not to mention that anyone with access to the database could make edits and you wouldn't know who. EDIT: Just want to point out that it appears that this software allows you to define access for different members of a team, but I haven't had a chance to try it.
- braderhart 10y ago
  That's what I'm suggesting though. I'd love to see a Qt/QML application that is like KeePass, but has built in support for external databases for users/groups.
- koolba 10y ago
  > The main knock against KeePass for teams is that it's all or nothing. ... and the binary format makes KeePass merges impossible. Even if it's just you, if you have multiple computers you need to make sure you have the latest copy before adding something. That's what's nice about pass, it plays nice with git, rsync, and just about everything else. Last write wins per credential. If you tack on history with git (or ZFS snapshots!) you have a central copy that you can share among a team. Someone should make a slick UI atop a pass directory with a browser plugin.
  - aeorgnoieang 10y ago
    Thanks for pointing out `pass`! I've been manually merging a set of Password-Safe-format password files (one for each of my many computers) and I've been thinking about alternatives for a long while. I was actually thinking about how I could combine encrypted files with Git to get history and painless merging – I'm glad to know that someone else had the same ideas!
    - drdaeman 10y ago
      Pass has one limitation - having filenames in plaintext. This could or could not be an issue for local repositories, but this is definitely an issue for remotes. Sadly, Android client (which is quite good otherwise) doesn't support git-remote-gcrypt.
      - aeorgnoieang 10y ago
        > having filenames in plaintext Why is this a limitation? Are you stating that each file in the 'repo' is encrypted separately? I figured it was the entire repo as a directory, in which case, when it's 'at rest', the whole thing is encrypted as a blob.
        drdaeman 10y ago
        > the whole thing is encrypted as a blob No, it's not. With pass (just to be sure - we're talking about zx2c4's one, right?), the store contains a bunch of independent gpg-encrypted text files. However, the filenames are not encrypted or obfuscated by any means. This has pros and cons. On the good side, you don't have to decrypt anything (which means, actually use your GPG key, which is best kept on an unplugged HSM) to just check if the credential's in the store (think auto-fill suggestion). Also, this architecture allows dead-simple (plain rsync or git!) approach for synchronization when there are no entry-level conflicts. On the bad side, anyone who has access to the filenames (local filesystem access or a clone of git repo) can figure out which resources you have credentials for. That's the price of the simplicity. I.e. what you see in the very first example at https://www.passwordstore.org/ https://www.passwordstore.org/ in the "Using the password store" section are the actual at-rest filenames. Run `ls -lR ~/.password-store` if you don't believe me ;) Use of ecryptfs/encfs or git-remote-gcrypt was suggested to mitigate this, but those aren't perfect. Well, everything depends on the threat scenarios you consider.
        aeorgnoieang 10y ago
        Sorry if this is too late to not be annoying. What're the downsides or limitations of ecryptfs/encfs or git-remote-gcrypt – I was looking over Pass again and realized all of what you stated. I figured ecryptfs/encfs would work well enough to encrypt the Pass repo itself.
chadk 10y ago
Because KeePass is built for individuals, not teams?
tvanantwerp 10y ago
Using KeePass is great as an individual, but it's been a huge pain for my team. I work with mostly non-tech people who are immediately scared-off by the unfriendly interface. I've had to silo credentials across several databases to keep sensitive things away from those who shouldn't have access (e.g., interns don't need banking logins). Lots of my colleagues just refuse to use it, preferring sticky notes on the monitor. I'm thrilled to see something like this which might solve lots of our current pain points.
antoncohen 10y ago
I think the FAQ does a good job of explaining it, basically it is for teams: https://www.passbolt.com/faq https://www.passbolt.com/faq Things like KeePass and 1Password don't scale well for teams/businesses. There are things like admin passwords that teams need to share (as bad as it is to share passwords, there are a lot of cases where there isn't another option). You can do something like store KeePass or 1Password in Dropbox, but it has issues. The vaults have a password, everyone using it needs to know the password, and everyone gets access to everything. You can't do something like share a billing password with someone in accounting, without also giving them all the root passwords. It becomes a pain to create a bunch of individual vaults for every sharing case, and keep track of and share the individual vault master passwords. Enterprise password managers also have audit systems. You can see every password someone had access to, every password someone accessed, and who accessed a specific password. I don't know if Passbolt is any good, it seems like it is off to a decent start. I've looked into enterprise/team password managers at every company I've worked for in the past 10 years; I've never found an open source one I trusted -- they all drop the ball in at least one critical area. And I don't trust the closed source ones either. It is a sad state of affairs, so I welcome new entrants into the space.

Why would I use this vs something like KeePass/KeeFox? I was hoping to see a new cross-platform Qt/QML password manager with Firefox and Chrome integration plugins.

thomnottom 10y ago

The main knock against KeePass for teams is that it's all or nothing. We've had to create multiple databases for different job functions, which becomes a pain to maintain. Not to mention that anyone with access to the database could make edits and you wouldn't know who. EDIT: Just want to point out that it appears that this software allows you to define access for different members of a team, but I haven't had a chance to try it.

braderhart 10y ago
That's what I'm suggesting though. I'd love to see a Qt/QML application that is like KeePass, but has built in support for external databases for users/groups.
koolba 10y ago
> The main knock against KeePass for teams is that it's all or nothing. ... and the binary format makes KeePass merges impossible. Even if it's just you, if you have multiple computers you need to make sure you have the latest copy before adding something. That's what's nice about pass, it plays nice with git, rsync, and just about everything else. Last write wins per credential. If you tack on history with git (or ZFS snapshots!) you have a central copy that you can share among a team. Someone should make a slick UI atop a pass directory with a browser plugin.
- aeorgnoieang 10y ago
  Thanks for pointing out `pass`! I've been manually merging a set of Password-Safe-format password files (one for each of my many computers) and I've been thinking about alternatives for a long while. I was actually thinking about how I could combine encrypted files with Git to get history and painless merging – I'm glad to know that someone else had the same ideas!
  - drdaeman 10y ago
    Pass has one limitation - having filenames in plaintext. This could or could not be an issue for local repositories, but this is definitely an issue for remotes. Sadly, Android client (which is quite good otherwise) doesn't support git-remote-gcrypt.
    - aeorgnoieang 10y ago
      > having filenames in plaintext Why is this a limitation? Are you stating that each file in the 'repo' is encrypted separately? I figured it was the entire repo as a directory, in which case, when it's 'at rest', the whole thing is encrypted as a blob.
      - drdaeman 10y ago
        > the whole thing is encrypted as a blob No, it's not. With pass (just to be sure - we're talking about zx2c4's one, right?), the store contains a bunch of independent gpg-encrypted text files. However, the filenames are not encrypted or obfuscated by any means. This has pros and cons. On the good side, you don't have to decrypt anything (which means, actually use your GPG key, which is best kept on an unplugged HSM) to just check if the credential's in the store (think auto-fill suggestion). Also, this architecture allows dead-simple (plain rsync or git!) approach for synchronization when there are no entry-level conflicts. On the bad side, anyone who has access to the filenames (local filesystem access or a clone of git repo) can figure out which resources you have credentials for. That's the price of the simplicity. I.e. what you see in the very first example at https://www.passwordstore.org/ https://www.passwordstore.org/ in the "Using the password store" section are the actual at-rest filenames. Run `ls -lR ~/.password-store` if you don't believe me ;) Use of ecryptfs/encfs or git-remote-gcrypt was suggested to mitigate this, but those aren't perfect. Well, everything depends on the threat scenarios you consider.
        aeorgnoieang 10y ago
        Sorry if this is too late to not be annoying. What're the downsides or limitations of ecryptfs/encfs or git-remote-gcrypt – I was looking over Pass again and realized all of what you stated. I figured ecryptfs/encfs would work well enough to encrypt the Pass repo itself.

chadk 10y ago

Because KeePass is built for individuals, not teams?

tvanantwerp 10y ago

Using KeePass is great as an individual, but it's been a huge pain for my team. I work with mostly non-tech people who are immediately scared-off by the unfriendly interface. I've had to silo credentials across several databases to keep sensitive things away from those who shouldn't have access (e.g., interns don't need banking logins). Lots of my colleagues just refuse to use it, preferring sticky notes on the monitor. I'm thrilled to see something like this which might solve lots of our current pain points.

antoncohen 10y ago

I think the FAQ does a good job of explaining it, basically it is for teams: https://www.passbolt.com/faq https://www.passbolt.com/faq Things like KeePass and 1Password don't scale well for teams/businesses. There are things like admin passwords that teams need to share (as bad as it is to share passwords, there are a lot of cases where there isn't another option). You can do something like store KeePass or 1Password in Dropbox, but it has issues. The vaults have a password, everyone using it needs to know the password, and everyone gets access to everything. You can't do something like share a billing password with someone in accounting, without also giving them all the root passwords. It becomes a pain to create a bunch of individual vaults for every sharing case, and keep track of and share the individual vault master passwords. Enterprise password managers also have audit systems. You can see every password someone had access to, every password someone accessed, and who accessed a specific password. I don't know if Passbolt is any good, it seems like it is off to a decent start. I've looked into enterprise/team password managers at every company I've worked for in the past 10 years; I've never found an open source one I trusted -- they all drop the ball in at least one critical area. And I don't trust the closed source ones either. It is a sad state of affairs, so I welcome new entrants into the space.