Is the OpenPGP thing supposed to inspire confidence?
Given OpenPGP's use of custom KDFs [1], weak default hash functions (SHA1) and questionable ciphers (CAST5? really?), it certainly doesn't for me. While none of this falls under the "completely broken" category, it certainly could be better... My main concern with anything using OpenPGP is that it only takes one of these things to fall before a deep compromise is possible. There's a reason many cryptographers are anti-cipher choice.
It'd be quite possible to write similar using NaCl/libsodium and achieve a higher margin of security.
"Because we believe system administrator appreciation day should be everyday, we started building a client based on nodejs." I must be a cranky system administrator because I find idea of using nodejs for a CLI extremely tiresome in a "get off my lawn" sort of way.
Sacrasm aside, saying "node.js" strongly implies use of npm, and that means pulling a lot (think deps-of-deps-of-deps) of potentially unaudited code off the network, without much authentication.
Not something one would fancy for a tool that handles sensitive data.
I was only being slightly sarcastic. I installed an app with a relatively small number of dependencies, and was shocked to see my node_modules directory contained over 100,000 files.
I chose RatticDB[1], but it looks like development has stalled.
Passbolt looks like an alternative worth investigating. Based on a quick look at the Git repo, it's been in development since 2012 (a shame I hadn't heard about it earlier) -- and it looks like Passbolt may be backed/bankrolled/funded by 'Bolt Softwares' (I have no issue with this - but I thought it's worth pointing out. I wonder if Bolt Softwares aims to commercialise the software in the future).
Is it possible to use Passbolt without a browser plugin?
Some suggestions (if the authors are reading):
* provide a more indepth "features" page
* provide a demo account (so I don't need to sign-up/disclose my email)
Thanks for the suggestions. We'll definitely come up with a feature/roadmap page shortly. As for the demo account it is a bit more complicated, but we'll look into it.
I see 1Password mentioned here, but not Dashlane. I use it personally across multiple devices and it has just been awesome. I was using KeePass before that for several years, but the inconsistent interface and performance across platforms became cumbersome.
Has anyone used both 1Password and Dashlane? Which one would you choose? Also, how is Dashlane for Teams?
I've recently experimented with Dashlane for Teams and been using 1Password Teams. 1PW has much more functionality around teams from my experience. The team sharing within Dashline leaves much to be desired, even sharing of multiple items at a time is a bit rough, and I couldn't find a way to create vaults/groups.
1PW has a notion of vaults for grouping data, but anyone with access to the vault can see all of the credentials. This makes it really cumbersome with overlapping groups that results in vault explosion. Eg, Marketing & Finance vaults have overlapping users, so you create a Marketing/Finance vault, and so on. You can see several questions about this issue in the forums.
Looks like the pricing is going to be $5/user/month for 1PW. I'm waiting for them to add individual item permissions and the ability to create custom groups. No 2FA either, which they have their reasons for. Auditing and reports would be nice.
I might end up going with LastPass for the more granular permissions. I really wish I could find a decently priced company credential/identity manager that can assist with things like automatically rotating passwords/access so I can more easily prevent staff from copying passwords into an unencrypted file, and get an audit log of who's accessing what. Dashlane has some notion of password resets but there's no control to script it for your own or client websites.
There's Thycotic but I don't think their Cloud version supports password changing (and I'm not interested in running a Windows server). There's also Manage Engine's PMP... but that interface also left much to be desired.
I'm so glad to see movement in this direction. I work on a team with lots of non-technical people who need to share passwords and secure information, and store their own private bits. So we use LastPass. It's the only thing that works for us, but man does it need some competition. It makes me sad several times a month.
I would love to be able to move away from their central repository and host our own solution with something like this. I just hope that any user testing is being done with some non-techies who don't know or care what a PGP key is.
I love the experience of using 1Password, and use it for my personal work and family.
Thanks for posting this, because the last time I had looked at 1Password for teams it didn't meet all the features of LastPass. I'll give it another look.
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.
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.
> 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.
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!
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.
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.
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/ 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.
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.
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.
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.
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.
This is looking fantastic. IIUC, the authentication section is telling me that each user will have a GPG key instead of a username/password. Is passbolt able to pull gpg keys of a user from some external source automatically?
Related: GitHub was working on a Rails based password-sharing manager for teams earlier (3yrs ago) called Swordfish. The code is still available, although I'm not aware of a maintained fork[0]. The readme has some nice links on the topic
I haven't found it in the code yet, but the landing page's protocol diagram with optional "/auth/verify" might have potential to be abused as a decryption oracle. It depends how they check the nonce.
The authentication token follows a very specific pattern to prevent this type of attacks. For example an authentication token would look like this: gpgauthv1.3.0|36|8661be60-23df-11e5-b16c-0002a5d5c51b|gpgauthv1.3.0. Both the server and client check for the consistency of that format.
Is the private key uploaded into the service at all? For a moment I thought it was, until I realized the URL was resource:// :)
Along with that, I would be interested in seeing the trust network being uploaded to an external backing service (Maybe in the same SQL database?) That way it can be hosted on Heroku!
Fantastic product. I'm going to take a real good look at it and host it myself I think. Just Heroku would have been 'easy.'
Given OpenPGP's use of custom KDFs [1], weak default hash functions (SHA1) and questionable ciphers (CAST5? really?), it certainly doesn't for me. While none of this falls under the "completely broken" category, it certainly could be better... My main concern with anything using OpenPGP is that it only takes one of these things to fall before a deep compromise is possible. There's a reason many cryptographers are anti-cipher choice.
It'd be quite possible to write similar using NaCl/libsodium and achieve a higher margin of security.
[1]: http://tools.ietf.org/html/rfc4880#section-3.7.1.3
EDIT: It seems my knowledge of this may actually be dated, GPG at least has shifted away from many of these defaults
https://lists.gnupg.org/pipermail/gnupg-announce/2014q4/0003...