For personal use: none for me. Instructions for deriving/obtaining my master password and physical key will be made available in any will or power of attorney documentation I get around to drawing up.
In DayJob there are several, though they are usually only temporary needs, such as:
1. We often get sent password-protected documents by clients, that more than one of us needs to read. It pains me how often I see an attached document on an email containing the password needed to open it… A shared password manager where someone can record the credential and mark who should be able to access it (or better have all credentials encrypted by the public keys of those who should be able to access them rather than just trusting a flag) would be less daftly insecure.
2. Distributing initial credentials for new assets or to new people, where those assets are not integrated with single-sign-on so nothing needs to be distributed anyway.
There are other ways to manage such situations of course, but a password management arrangement with a well-defined way of sharing credentials may encourage behaviour more secure than some of the ad-hoc solutions people regularly use.
Internally I do something very similar: drop the information to a share on my machine with read permissions set to the right people.
As you say, things can be more complicated for externals. I often don't have write access to much that they can read from, without putting in a request through infrastructure, for obvious separation-of-concerns reasons, because things we host/manage directly for them are well locked down, anything at their end is too, and most of our clients have white-list-only access to other resources.
Comments
> What's the use case for sharing passwords?
For personal use: none for me. Instructions for deriving/obtaining my master password and physical key will be made available in any will or power of attorney documentation I get around to drawing up.
In DayJob there are several, though they are usually only temporary needs, such as:
1. We often get sent password-protected documents by clients, that more than one of us needs to read. It pains me how often I see an attached document on an email containing the password needed to open it… A shared password manager where someone can record the credential and mark who should be able to access it (or better have all credentials encrypted by the public keys of those who should be able to access them rather than just trusting a flag) would be less daftly insecure.
2. Distributing initial credentials for new assets or to new people, where those assets are not integrated with single-sign-on so nothing needs to be distributed anyway.
There are other ways to manage such situations of course, but a password management arrangement with a well-defined way of sharing credentials may encourage behaviour more secure than some of the ad-hoc solutions people regularly use.
Sometimes I write the password in a file in the home directory of a server we both access in ssh. It doesn't happen often, maybe not every year.
A customer has no servers, not a chance with them.
Internally I do something very similar: drop the information to a share on my machine with read permissions set to the right people.
As you say, things can be more complicated for externals. I often don't have write access to much that they can read from, without putting in a request through infrastructure, for obvious separation-of-concerns reasons, because things we host/manage directly for them are well locked down, anything at their end is too, and most of our clients have white-list-only access to other resources.