Password sharing without making everyone create yet another account

December 4, 2021 12:56 PM

We need to share passwords with people collaborating on a project. We don't want to make everyone create another account with another service. Is there a password manager or related tool that offers a passwordless authentication option?

Bonus points for:
- FLOSS (free/libre/open-source software) - we may be able to self-host if necessary
- granularity in how passwords are shared (e.g. I can grant Jerry & Rosa access to passwords tagged "fundraising", and grant Kamala & Joe access to passwords tagged "administration", etc.)

posted by sibilatorix to Computers & Internet (10 answers total)

Many password managers (1Password, for example) offer a feature where you can send someone a link to view the username/password info for an account.

Then that person can use whatever password manager they prefer to save that information on their end.
posted by mekily at 12:59 PM on December 4, 2021

We don't want to make everyone create another account with another service.

There are two basic steps for this sort of thing: Authentication (AuthN) andAuthorization (AuthZ). Authentication is "how do you know the person on the other side is who they say they are?". If you don't want them to create another account with another service then you could possibly use OAuth (the whole "sign in with Google/Facebook/Twitter/etc.") and fall back onto "if Google says "it's bob" then it's 'bob'. It would be so much easier to just throw up a basic site somewhere with an SSL cert and have them create an account there and login (or cookie stay logged in) just like every other site.

The Authorization part is rather simple after the Authentication is taken care of. There are probably several things Content Management System (CMS)-like that would do the permissions to Create/Read/Update/Delete an entry (in this case password info).

The passwordless authentication you mentioned is the harder version of this based on Public/Private Key cryptography and requires even more to get going. You still have to somehow collect/exchange/verify the that the keys belong to the right person. You either have to create them yourself and somehow send them to the user, or the user has to create their own and send it to you, and either way you still have to have some way to make sure the right people are on both ends of the transfer.

All of the really "no new account" methods I can think of require much more complex effort on both sides (and Technically complex at that) than just having them create an account on your site and maybe making a phone call.

I've done this a few times in $WORK environments using hard things like Kerberos or SSL certs on both sides of the connection. The complexity there is way way way more than having them just "make an account, verify over phone".

It will be interesting to see what other possibilities turn up.
posted by zengargoyle at 2:23 PM on December 4, 2021

Response by poster: @mekily: Thanks, that's good to know! Not quite what we're after, but it might be the best available right now.

@zengargoyle: We can self-host something that exists (e.g. BitWarden, if it had the features we're after) but we aren't going to be developing a webapp or repurposing something CMS-like. That would be too much of a digression from this group's main purpose. Thanks for the background, though!
posted by sibilatorix at 3:10 PM on December 4, 2021

If you can send a link, you might as well just send the username/password directly. Zero security added.

Check out Pass: The Standard Unix Password Manager. Specifically the other clients. This could work in a non-web sorta way. Probably easier if the holder of all the passwords and authorization info is on a Mac or Linux sort of machine (easier to automate, Windows is a PITA). Each user could set it up and send you their public key. The keys have a sorta small fingerprint that could be confirmed over the phone. Hey bob, is this your key? What's the fingerprint? "0AEF 848C BDDF". Checks out OK then.

Then you take your list of passwords and pare them down to the ones bob has access to. Encrypt them with bob's public key (you don't even need to know his private key or the private key passphrase). You have a directory of encryped files that only bob can read. Zip them up and mail them out (or just make them public, yay! encryption). Bob then unzips the folder's worth of passwords, points his 'pass' at it and BAM, bob has passwords. Maybe even browser integration.....

Basically you can't really get around the actual authentication bit. That bit boils down no matter how you look at it into a phone call or zoom session or some other way for two people to securely share a primary secret. Or in the case of the GPG public/private key system.... just confirming that the public key that says 'bob' on it really is the right 'bob's public key.

Sorry this stuff is such a pain. Seriously, it's why GPG encrypted mail or end-to-end encryption for messages, and all of that other share-a-secret stuff is so hard to actually do. The easiest is in person and just handing a slip of paper with the new "you know what" written on it.

I just fear that the "create another account" make it easy... sorta makes it impossible. At least beyond anything but security through obscurity.
posted by zengargoyle at 5:09 PM on December 4, 2021

I'm here to advise against password sharing because it removes auditabilty. You will _not_ be able to determine who did what, even if it's something as simple as 'who was logged in when this document changed' as every action in the log will have been done by the _same_ account. It is convenient, yes, and you get by until something goes wrong and management, auditors, or security staff want to know how it happened.
posted by TimHare at 6:02 PM on December 4, 2021 [2 favorites]

We need to share passwords with people collaborating on a project. We don't want to make everyone create another account with another service.

That's a great pity, because securing a collaborative effort is a non-trivial undertaking that has many security failure modes that simple password sharing will simply not protect against.

I would not even contemplate doing something like this by sharing passwords given that Keybase exists and has a very well-thought-through Teams feature for exactly your kind of use case.

I understand the unwillingness to make people sign up for yet another messaging/collab service, but seriously, the amount of work involved in setting up password sharing in anything vaguely resembling a secure fashion is going to be greater.
posted by flabdablet at 6:49 PM on December 4, 2021

Response by poster: Some of the services we are working with will not provide us with multiple user accounts. We have one account for the service, and multiple people need to access it. This is suboptimal, but unavoidable.

For most of these accounts, unauthorized access is not the primary concern. We are more worried about situations in which (for example) I am the only person who has the password for the mailing list, I get run over by a bus, and suddenly nobody can log in to fix the mailing list when it breaks.
posted by sibilatorix at 8:39 PM on December 4, 2021

Have a look at TeamPass. It's free and open source, GPL 3.0. We use it at work, where it's used in a mixed Windows AD/Linux environment and accessed via a web browser. Access to passwords or groups of passwords are managed via permissions, and all our users enter the app via our Windows passwords. I don't administer it, so don't know how it's set up and managed, but it works well for us.
posted by lhauser at 9:53 PM on December 4, 2021

You might also care to look at KeePassXC. It's a simple file-based password manager, and its password database files can be encrypted using a master password or a key file (which can be any file you like, but it's separate from the password database and would typically be kept on something like a USB flash drive, or in somebody's phone) or both. Using only a key file would give you the passwordless authentication you want.

If you need different groups of people to hold different sets of passwords, you can just make as many password database files as you need. KeePassXC can keep multiple database files open at once and allows you to clone and move entries between them as you like.

KeePassXC is a cross-platform reimplementation of KeePass, which supports the same password database format. Both are open source. There are also multiple phone-based apps that support the same format; some open source, some not. I use KeePassDroid on my Android phone and I'm completely happy with it.

Distribution of password database files can be done using any file sharing service, or even by sending them around as email attachments: the encryption is good enough to make the latter completely safe, as long as you're using decently long and random master passwords or key files distributed properly securely. Personally I use Dropbox because I've always found it the least buggy of the available cloud file sharing services. Installing both Dropbox and KeePassDroid apps on a phone allows for easy opening of the password database just by locating it inside the Dropbox app and then tapping on it.

Access revocation will be the main difficulty with any shared-password scheme. The only way to revoke access for somebody who has ever had a copy of both your password database and its key file, or (equivalently) access to any cloud-based password management service, would be to change all the managed passwords on all their associated services, and then re-publish the password database keyed to some other master password and/or key file. You cannot rely on simply changing the central master key to lock out people whose access you want to be sure is revoked, because they could easily have copied all the passwords out before you did that.
posted by flabdablet at 10:36 PM on December 4, 2021

Lastpass has a secure password sharing option if you have the premium version. Free version only allows 1 to 1 sharing.
posted by kschang at 12:03 AM on December 5, 2021