[ctvo]

> Why are large businesses “sharing passwords” between users? What happens when one user leaves?

Because not all products businesses use have fine grain authentication and authorization. For example, their registar for their domain names. And differing employees need access to it at different times.

> Isn’t sharing a password in a business context like “Things you shouldn’t do” 101?

What do you think Bitwarden does? It's fine grain authorization over shared resources (passwords) that control who can access them. You categorize, create roles, and give those roles access to specific passwords. When an employee leaves, you rotate the password. Every access is recorded for auditing. It solves a real business problem.

[noirbot]

It's also useful for things like secure temporary password delivery. I set up your account for the first time with a new service, generate a temp password you have to reset on first login, and then share it to your Password Manager space.

Also just useful for things like API keys - my team just has all of our team's allocated API keys for various services in our password manager so we don't have to go look them up in all of the various service's sites if we need them.

[scarface74]

I understand the temporary password use case. But what do you do when an employee leaves? Do you change all of the API keys?

[noSyncCloud]

Aren't we supposed to be rotating our keys when someone leaves no matter what technical solution to this problem we're using?

[scarface74]

Well, I was trying to avoid the entire rant about using API Keys for security in the first place.

https://zapier.com/engineering/apikey-oauth-jwt/

https://cloud.google.com/endpoints/docs/openapi/when-why-api...

We all have done it at one point or another. But if I am ever in the middle of a technical presentation and mention “API Keys”, I get all types of dirty looks from security.

Notice that Square for instance strongly discourages API Keys for production.

https://developer.squareup.com/docs/build-basics/access-toke...

On the AWS side (where I work) we always discourage long term use of access key/secret keys for accessing resources even though I realize it’s necessary for some integrations. Even then, most organizations also put a condition that you can only use it from known IP addresses.

[scarface74]

Now I’m curious and this comes from my job history is working at mostly small disorganized companies and then moving to one very large company where I work with other very large enterprises so I have no experience with mid size companies.

Say I work for a large company where everything is gated via an SSO - email, Slack, internal apps, ADP for payroll, my brokerage account containing my 401K information (of course I do have a separate non SSO password for this since it is my account), and Bitwarden (I see it does support SAML).

If I leave my very large organization, it’s easy enough for a manager to disable my SSO and be mostly assured that I don’t have access to anything I shouldn’t. Because “security is job 0” (How do you say where you work without saying where you work /s).

Now let’s say that BitWarden stores 10 passwords to external services and I had access to those passwords through Bitwarden. Does someone then have to go in and manually change passwords to those 10 services every time someone leaves?

[ctvo]

> Now let’s say that BitWarden stores 10 passwords to external services and I had access to those passwords through Bitwarden. Does someone then have to go in and manually change passwords to those 10 services every time someone leaves?

To reframe this: Companies use both SSO and BitWarden, but because a typical company utilizes so many differing services with differing auth coverage (supports SSO? supports roles, permissions, etc.?) BitWarden fills the gap. BitWarden wouldn't be used for your ADP, and 401K. It may be used for your company's payment processor under one main username / password. It may be used for your root AWS account username and password. It may be used for your DNS management. Production API keys for Stripe may be stored there in plain text, but encrypted in your secret store of choice. Those are the typical use cases I see. The list of things you keep in BitWarden are small(er), but they're business critical. Whereas before they were held by the CTO of the early stage startup, now they're centralized, secured, have an audit trail, can be easily shared with others, etc. etc.

In the company I used BitWarden with, these passwords were rotated manually when an employee who had access to that password left and the new value updated in BitWarden. Maybe that's easier now?