Ask HN: How to store and share passwords in a company?

You generally want to minimize the number of passwords you manage; for instance, you should generally be paying the SSO tax and getting as many services as you can onto OIDC. After that, just do the cloud version of 1Password, which is easy to audit and manage access for, which you'll thank yourself for when it comes time to SOC2.

Remember, as you give people access to passwords, that those passwords will need to be rotated when those people change to incompatible roles or depart the company. If passwords aren't a total pain in the ass for you, you're probably doing something wrong.

We tend to have zillions of passwords in IT jobs right?

Yes, but they should be unique to your account. I.e. via SSO.

What are the recommended ways to store and give access to passwords?

Whenever possible, don't. Otherwise, it depends on the scale and security you need. A password manager is one possible solution. Another solution is something like Hashicorp's Vault or OpenBao.

How can a new hire be given access to all required passwords day 1?

They should access it through their SSO account, and not need a billion passwords across systems.

And when such new hire gets promoted, how can we give access to the additional passwords they will need?

Again, whenever possible, tie access to their SSO account.

And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?

Well if you did all of the above this wouldn't be an issue, you just close the 1 account.

Any best practices? Any 80/20 suggestions? Low hanging fruits? Any warnings about what not to do?

Another thing you can do is give people 2 accounts, a normal account and an Admin level account, this is useful for things where the employee needs a regular day to day account as well. i.e. for the employee self portal for instance.

Don't. Give them access to all systems they need with their own user/password. That way you can revoke them (if/when necessary) without disrupting everyone else.

Also automate as much as is reasonable, e.g. github access to push code to a dev branch, then enqueue merging of it. But a CI/CD pipeline does the actual deploy, the employee doesn't need to access any of the production systems. A very small number still will, but that's a much better situation.

Give the employee 1Password to manage their own passwords.

We always used 1Password[0]. We still use it in the open-source projects that I work with.

I have heard that LastPass is about as good, but have no experience using it.

The latest version of 1Password isn't so good, but it works fine.

[0] https://1password.com

People overwhelmingly recommend SSO. Isn’t that lowering the security level? If that single account gets taken over, the attacker has access everywhere else too.

Some places let you configure SSO+2FA, which helps; but in most cases clicking a social login button gets you full access.

And speaking of a single point of failure, cloud password managers look even worse[1].

[1]: https://thehackernews.com/2023/02/lastpass-reveals-second-at...

Just want to say that StackExchange is the place to get answers for questions like this (waiting for my downvotes). Is there a better place?

- Use 1Password or similar password vault to deliver account passwords on day one; the password manager also promotes good personal password management practices

- only share passwords for personal accounts; those accounts you terminate when the employee separates. For shared resources, use SSO and SCIM group management via the SSO provider to add and remove accounts from groups with different roles.

Rippling seems like a neat offering because they bundle SSO with HR people management, and their HR product is the best I’ve used as an employee - hopefully the administrative side is just as good or better.

If those SaaS tools aren’t in your budget, try looking for open-source or gratis alternatives with the same shape, or repurposing whatever IT infra you have to implement a similar model.

I'd strongly advise against 1Password, several answers here recommending it and I suspect conflating personal use with 'good enough for business', hard disagree.

Your company can apply various aspects of threat modelling and more often than not several companies I've worked with find that Bitwarden self-hosted can meet a lot of requirements, this is the best solution in terms of privacy and security and controlling your trust boundaries. Failing that, Bitwarden Enterprise (they host) is also just as good. In either case there's granular controls for controlling what your new hires can be given access to.

There won't be a perfect solution such as notifying everyone about rotation, it's not needed though - simply rotate it and the next time they need it they get the new version.

Of course the general advice is something I agree with - use SSO where possible, but I fully recognise that it isn't always possible with some third party services that haven't implemented it yet.

There is a cruder solution I've often seen too, it's a bit painful but KeePass2/KeePassXC on a company hosted SAN is the ultimate offline, fully controlled solution but comes with extra hurdles to access, whereas Bitwarden is browser based and simpler to use.

KeePassX file in a repo with long password is a reasonably good solution. Not perfect, but open source and you can segregate by user/team. Also in a team there can be 1 person who has write/update duties and updates the passwords if there a shared ones (not the best approach).

BTW, not related to the passwords is to put everything non-public serving behind a firewall and access it only via individual VPN keys.

Lots of people suggest 1Password, and it works really well for larger or more disperse groups needing some shared vault capability, and perhaps those that want a more visual-driven web interface. Keep in mind there is the per-seat pricing for that.

What has also worked really well in the past for me and my teams, especially if they are more technical and these credentials really never need to go beyond this more technical team is setting up a single 'vault' encrypted with GPG. Each team member then gets the vault re-encrypted for them, adding them to the recipient list. While this takes a little bit of effort to get a workflow going, it keeps it out of a cloud service, if you're concerned about that, and you get to pass it around just like any other file. When someone leaves, or no longer needs access, their recipient is removed and then the file recommitted and redistributed. In the past I've had the ASCII-armored file committed in git and people just pull down a tools repo every so often.

If you are wanting to store credentials for, say, public cloud services, don't. Use roles as much as possible, don't pass around passwords, don't bother setting up individual users beyond those required to bind a role to it, grant only by roles as much as possible.

I can only say that using pass (https://www.passwordstore.org/) is an absolute nightmare, in case anyone else is considering that

It seems like perfect simplicity built on time-tested cryptography: store pgp-encrypted files in a git repository. We already had an internal git server and used PGP internally, it was the perfect marriage. The tool provides the common functions like selecting which colleagues to encrypt for, finding an entry and copying it to clipboard... but think of the moment your organization changes. Everyone has access to everything offline, which is great if you need it in a rainforest or when the server is down, but also you'd need to rotate all exposed-to-them entries whenever someone leaves. Re-encrypting everything to remove an old key is pointless because the git history will provide an attacker with whatever version they need.

Offline access is useful for selected credentials (like the disk unlock password for some central servers) but, to avoid unnecessary rotations, should not be the default unless you're a sysadmin mentioned on disaster recovery team

Skimming the recommendations, so far there are no tools mentioned that don't require maintaining another service or that can't read your data. At least pass had that going for it

I've built security programs at 3 companies. This is how I would solve these problems.

1. SSO everywhere. Okta if budget is no concern and Keycloak if it is.

2. Password manager for the entire company. Even if it's possible to go SSO everywhere, there are still secrets employees will need to manage. Give them a solution or they'll solve it on their own and not in a good way. I like 1Password.

3. All services use a secret solution that can broker short lived secrets and a policy that limits secret TTL to a day or less. I like HashiCorp Vault.

1Password has shared vaults, 1Password for Business has the concept of groups.

Question: has anybody actually worked in a password-less or even “zero trust” environment?

Most environments I have worked with struggle with sharing passwords like OP and it’s a massive pain. One time, dev team was sharing active directory credentials to access service. At some point service account gets locked because someone was using an older password of the account.

Usually a quick problem to solve with 2-3 people in same region (or prevented entirely), but teams across time zones and countries (US vs Vietnam or India). It becomes painful. Doesn’t matter if they are “senior” or green/“junior” engineers.

If I ever have my own company, I want my own internal IdP (identity provider) and all internal and external services integrated with it. Employees issued (multiple) physical hardware keys. This is required to authenticate with work computer and subsequent access to VPN/tail scale.

Individual services and products must support oauth.

Access to public cloud resources? AuthN through company IdP. Admin creates roles for you to access resources necessary for work

Access to database? No shared passwords. get admin to add authorization, then authN via IdP and get access token

Version control? Same as above.

E-mail? Same as above.

Company document repository? AuthN through IdP which requires physical security key.

Access to company laptop/desktop? Plug-in security key. Permissions/roles managed remotely (give bob sys access for dev work but jenny from HR is given very basic system access).

Then once you are done, then remove security key and all established sessions are removed and logged out of computer (or just locked).

Employee leaves? Just disable the account. Maybe leave a small window of access to certain services (ie, email) so they could say their goodbyes, turn in company equipment. Then revoke access completely.

Hostile or state actor obtained security key of active employee? From IdP, mass revoke all access. Can also track what actor accessed as well.

With this, problem OP has proposed has disappeared completely.

Never bind critical services to the account of one employee. When that one employee gets hit by a bus you loose access to critical infrastructure.

Folks are going to have strong opinions here about things, so I'll try to stick to my personal experience. I adopted 1Password at my current organization. Overall, I've been very satisfied with it. Here are the major points I've noticed:

* Great authenticator support. We have some accounts that our team members have to share, and we want MFA on those accounts. I can add an MFA field to 1Password entry and the people who have access to that entry can use it. Doesn't help when those entries require phone/e-mail based MFA; I'm working on a little Twilio / outlook group setup to take care of that. * Easy to navigate group membership. Passwords are stored in vaults and individuals or groups can be given access to those vaults. The model for it fits in my head and I like that. * Easy share ability. There are a few credentials that I occasionally need to share outside of a vault. I can create a link and grant access to specific individuals for a given amount of time. * The browser extension and integration have been really smooth in my opinion. * I find tagging and taxonomies of tags to be helpful, and 1Password supports those well. * We've gotten some great mileage out of 1Password connect. Some of our infrastructure secrets now reside directly in 1Password, and 1PW connect pushes them into our k8s environment as secrets where our apps can refer to them. Makes secret management across environments that much easier. * SCIM support (which I haven't yet implemented) and SSO support to bring more convenience for end-users. * Easy ability to recover if an employee forgets their master PW (have done this a handful of times). * A nice perk: our 1PW business comes with a free 1PW personal subscription for people, completely separate. If the employee leaves they have can convert their personal vault to a paid subscription or export it.

To answer your questions specifically based on my current context:

What are the recommended ways to store and give access to passwords?

1Password vaults. One vault per style of responsibility. 1+ groups have access to a vault. People get put into 1+ groups.

How can a new hire be given access to all required passwords day 1?

In our case, day 1 they accept the 1PW invite in their inbox, and then we assign them to groups. Done.

And when such new hire gets promoted, how can we give access to the additional passwords they will need?

Keep those "tiers" of passwords in separate vaults. Update the groups when someone's role changes.

And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?

See what groups that person is in and what vaults they had access to. Review "high priority" items which you've tagged in such a way as to surface them. Send an e-mail to the members of the vault telling them you're rotating passwords. Rotate the passwords. Anyone who's a vault member can see the password history too, I believe, so if something goes wrong the old password will still be available.

It really depends on how mature your org and stacks are. This is generally how I would do it.

1-20 people - password manager (bitwarden, 1pass, etc.) 20-30+ people - SSO

50+ people - start assigning real roles to your SSO schema

1-5 services - secrets in CircleCI and password manager is good enough.

5+ instances - use a secrets manager like Vault.

10+ instances - start using a secrets manager locally as well for dev. Start to consider using well scoped IAM policies for each of your services and team members.

15+ instances - start to think about adding additional zero trust boundaries.

Of course, this is very rough. Depending on your regulatory/compliance requirements and how much revenue you’re bringing in and from who, you might have to do this stuff sooner. In general, it should go:

1. Centralize secrets even if you can’t easily revoke people (password manager).

2. Make things easily revocable and centralized (sso).

3. Make roles and access finer grain (RBAC).

4. ^ with automation between all of these steps where it makes sense.

Something I would warn anyone of is building your own auth/secrets core tooling. This stuff is incredibly complex because of the edge cases and it’s just not worth the risk you take on by saving money unless you have a really good core business reason to roll your own. It’s also dangerous to prematurely optimize and pay the SSO tax too early. You will find that a lot of engineers appeal to emotion when it comes to risk. Something extremely helpful is going through and actually assigning a security risk score for all your systems. This might be tedious, but it brings a lot of clarity to the conversation of “what do we want to build when? What risk can we take on at any given stage?”

LastPass, Keeper, or 1Password. This is a fully solved problem you don't need to ask SO about.

I work for a financial, we take security seriously. Production secrets like passwords, private keys etc are stored in Hashicorp Vault. They aren't stored on disk anywhere else. Privileged system account that runs the production processes can't be used by interactive users. SREs can get access if they have to but its locked down and every session is recorded. The secrets are rotated regularly. So your new hire never gets to see production passwords effective.

For developers, everything is done in their individual accounts, no system accounts. There is a dev system account that does leak out some times but this is frowned upon. Production data that is synced to dev environments have to be scrambled so devs dont get to see all the real prod data.

1. Don't have passwords. This is why there's an "SSO tax". If you setup SSO then there will be less passwords / accounts.

2. Use a password manager that enables sharing. There are 1s with company accounts and different ways to share. A new hire can pick up a certain role/group and get all the passwords.

Zoho Vault

Use SSO when possible and fallback to 1pass vaults when SSO isn’t possible

honestly wonder if this is a 1pass ad thinly veiled as a question on the hn front page? if you have to ask, you shouldnt be doing it - hire or at least consult an IT professional

1Password for Teams for individual and group passwords. It’s great.

Use Okta for SSO.

At my previous work 1Password was replaced with Keeper. The main reason was better integration with SSO as Keeper can be unlocked with SSO itself so the user needs to remember just single password and for the rest either SSO was used directly or Keeper was used for other passwords.

Yellow sticky note on the monitor?

We use Delinea Secret Server (formerly known as Thycotic Secret Server) for several years to store all credentials. No affiliate. I am user of the system and not an admin, so can't comment on the admin part, but for an end user it works very well. We are consultancy and we use it to store all credentials to our clients systems. You access through a web interface. Had made my life easy when it comes to managment of my credentials.

You might want to take a look at Infisical (https://infisical.com)

Most services are connected through SSO, so those won't have passwords and are automatically shut down when the user leaves the company.

All employees also have a 1password account for which we can store individual passwords for the services that are not connected through SSO.

For some services we only have a single token/service account which we need to share within the team. Often they were stored in a `.env` file, but that tend to be a burden for onboarding and quite a bit of maintenance for each individual.

Within my current team we share them using direnv and https://github.com/tmatilai/direnv-1password. Secrets are loaded as environment variables whenever the dev enters the projects directory. They are loaded from 1password which is unlocked using fingerprint scanner. This way the secrets are not actually stored on disk.

People leaving the team does still require manual password rotation, but at least not everyone in the team needs to update their `.env` file this way.

(Personal background: I currently work in the enterprise identity space, where problems like this are bog-standard.)

Everyone else seems to be going on about SSO. That's good for end users signing into websites & laptops, but I'm getting the sense that you're more worried about admin-level permissions management.

First, some terminology to help you Google for things:

new hire be given access to all required passwords day 1

when such new hire gets promoted, how can we give access to the additional passwords

if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access

The more technical/sales-y way to say this is "I want a PAM solution with JML workflow integration for my secrets management" (JML: Joiner, Mover, Leaver, PAM: Privileged Access Management), and it'd be part of your overall identity management (IdM) strategy.

Some big-name companies in the IdM space: Sailpoint, Quest One Identity, CyberArk. Those'll give extended management of your canonical source(s) of identity & authorization info (typically Active Directory/Entra ID, but with the big-name products you can also integrate with modern solutions like Workday, FOSS e.g. LDAP servers, or old-fashioned stuff like CSV drops on an FTP share, and set up push or pull workflows to set user attributes & permissions based on your needs).

So you want IdM, plus (at least) 1 of 2 things:

1. Secrets management (for static secrets). I've personally seen folks using Thycotic Secret Server and LastPass Enterprise (although there's lots more companies in that space). That gets you the basic "get admin X a password that was created by admin Y". This is more of a requirement for servers you can't integrate IdM with (so it'd be licensed to admins only), because for day-to-day admin work (stuff like "add this user to that group"), what you'd ideally want is:

2. Full PAM. Essentially, you'd set up a workflow to temporarily "check out" a secret (i.e. password) for a set period of time (which the user could request some capped number of extensions to), that's then automatically-changed by the IdM once their time's up. (You can also do things like "give anyone who asks & gets manager signoff group permissions to XYZ that expires in 90 days".) Sailpoint and CyberArk can both do this.

Now, all that's for server admin. If you're talking about handing out admin permissions for endpoints (this is your classic "Tech support needs to privesc to fix something, but I don't want to leave the Windows admin passwords lying around in random techs' clipboards, and I don't want to let just anyone use ADUC (which, IIRC, is required to effectively use LAPS)"), you want something slightly different (in addition to an IdM solution):

3. EPM (Endpoint Privilege Management). BeyondTrust is the big name here. This lets you grant some permissions to end users (e.g. "install pre-approved software", "change (only some) networking settings"), while locking everything else behind an admin account (which you can gate access to using your PAM; that gets you auto-rotation of Windows admin PWs right after they're touched, plus JML workflows for your tech support personnel).

Now, go forth and Google (and when you start asking for demos, try not to let the salespeople drown you in buzzwords like I just did)!

I'd use `pass`, which I use personally, but it's a hard sell for people not as technically proficient. I've worked with all kinds of solutions both online and on-premise such as 1pass and vault. Ideally a meticulous SSO setup would replace all passwords except for perhaps one; the user identifies to the IdP, which then relays enough information to dependent parties to determine what that user can do. The problem is that getting proper SSO, identity and permission support across all software in use in a company requires a level of effort that few are willing to pay for internally these days, though newer software is a lot more flexible and usually has proper OIDC support.

On the other hand, external SaaS is still hard to integrate into your own IdP, so I guess we are stuck with some forms of passwords for some time to come.

Shared passwords should always be an exception. Prefer SSO. However the exception will always exist, in which case:

Some suggest using KeePass or equivalent, but I advise against it - too easy to copy and leave with the vault and very difficult to audit.

Find a solution that audits who had access to such password. And do your audits!

Consider rotating your shared passwords frequently, especially any high privileged ones.

If your risks warrant it, check for a PAM (privileged access manager) that acts as a middlemen and fully hides the password.

I realize I am not really answering your questions, so I'll stop here. But... SSO and proper directory management!

Use SSO where possible, and use a password manager like 1password, onelogin, or bitwarden when you have to.

There has been a lot of good mentions so far for permanent solutions on storing secrets securely..

On the other end, I'll chip in on https://onetimesecret.com/ for quickly sharing a secret. It will only allow the consumer to view the secret once, after that, the secret is no longer available. You can also set up One Time Secret with your company domain (self-hosted, I presume)

Long ago we used to stuff them into Keybase FS at a defunct startup I worked for. This worked pretty well and also meant when you needed a password you could just cat a file.

Since you asked for warnings about what not to do, here's one – don't share passwords! With shared accounts, you won't be able to tell who did what. If it is an important thing to which you are sharing passwords and bad thing happens, due to user action that is either accidentally or maliciously, you won't be able to find out who exactly did it and take corrective action.

In my experience, the surest way to security mess ups are when frustrated developers share credentials due to an overcomplicated sharing process of credentials. This obviously should not happen, but is why I am an advocate for 1Password.com.

They've made it simple for admins and users alike.

The first step for safely sharing passwords is not doing it. SSO as much as possible, give people actual accounts where not.

As a last resource, at a Former Employer™, people put a public key in their profile, and we used GPG to encrypt secrets and paste the encrypted value on Slack/Teams. This was only among developers, and there was a tutorial for setting up the GPG GUI and encrypting values with it, so it worked fine. But we did also actively worked towards not needing that as much as possible.

Self hosted Bitwarden instance?

Microsoft's Active Directory either managed or self hosted and you'll have SSO

KeePass in enterprise form with Pleasant Password Server. Supports many things including SSO. Of course it is local.

Strongly recommend using Bitwarden with various collections for different types of things. When someone leaves, we rotate every single password which was in a collection they had access to. It's a massive PITA, but it works /shrug.

Other than the popular password managers mentioned you can try Password Pusher [0]. It's open source, can be self-hosted, and has options like expire link after n loads or days.

[0] https://github.com/pglombardo/PasswordPusher

A password manager with some documentation and process could solve this.

What I describe is more or less what has been the standard at the companies I worked for, no secret sauce here, and I added some extra processes to address the questions you asked.

Get a password manager service (none of the keepass file thrown onto Google Drive), we used 1password, it's good enough I assume. Keep related items in one collection, don't mix unrelated items. Always save passwords in the pw manager, and make sure everyone does that, too. When someone joins, give them access to what makes sense. If someone gets promoted, add them to a new collection. Document who is allowed access to each collection if necessary. When someone leaves, kick them out of the password manager service first, then in a timely fashion, change the passwords (I don't know if you can do it automatically, but if churn isn't too bad, you can also do it manually). Save the new passwords in your passwords manager. As everyone uses the password manager, they will automatically get the new passwords without them even realizing it changed.

Some extra that's also important: if possible, use SSO and everyone uses their own account, eg Okta. Create and share passwords only if needed. When one off accounts are needed, make sure they are created with company email addresses, ideally named after a team rather an individual.

My experience is that most companies can't be bothered to change passwords every time someone leaves. Most people are not assholes, or want to go to court and possibly jail for messing around in accounts from their old companies (even if they could technically save the passwords for their own use for later).

Don't think that SSO is a magic solution for all of this. I'd say SSO won't work with any of it. SSO will work for new integrations but typically a team and team members will need passwords or API keys or tokens (all of these are strings, in effect passwords), and for that, beyond SSO, I have used and can recommend, for many teams in large organisations:

- A secrets manager (e.g. AWS Secrets manager) with an API key for each team, and the team can access their secrets on a team level there

- An encrypted file encrypted with e.g. KeePass, and one password for that

- Bitwarden or Lastpass on a team or department level (yes, shared passwords, for example where there is one password for one proxy)

- Yopass https://yopass.se/

On-premise version of Passwordstate. The even have a free 5 user license to trial it out. Integrates pretty well with your browser via a plugin and has a gazillion options. Permissions to passwords can be set at the individual passwords. And no I don't work for Passwordstate, just another satisfied customer.

Google SSO + KeePass file synced via Google Drive

Reduce the number of passwords the user needs via SSO.

Be absolutely strict on password sharing via non approved means.

Bitwarden enterprise for whatever is left, with collections per team/department.

I use LastPass, and know that they have been breached before. I am in a smaller company, and force strong master passwords, as well as monitor password security. Assuming that LastPass is not the solution I should use, is there a simple way to migrate to another service such as 1Password? I see people mention the UI being difficult for LastPass, but I do not find this to be true, and it makes a lot of sense to me from a security standpoint. I have specific groups, and use shared folders with group and/or user permissions.

Any help/advice would be greatly appreciated, and thank you in advance.

It's a fork and refactor of another comparison of password manager software I found.

https://password-manager.soft-wa.re

Cyberark works great for this, it even lets you avoid having to share passwords for things like ssh and rdp. There are several vendors in this space. The new hire in your scenario would be added to the right group, that group's members would have access to the right PAM tool vault. when they leave the company, they get removed from that group, thus removing their access. Shared passwords can also be managed passwords that get auto-rotated every so often.

Bitwarden is the answer.

If you don't have much of a budget, then it can be self-hosted using VaultWarden which supports the various BitWarden clients

https://github.com/dani-garcia/vaultwarden

Bitwarden can be used with groups, or even Google Sheets or something with proper access control (both are just kv after all... both should require 2fa, and both include auditing)

There's no good solution imo for what I think you're asking for (and that isn't: how can I share passwords for services that allow SSOv?)

"This reminds me of a problem that I wanted to solve in the future, but I don’t have the expertise. The problem is when an organization has a single account on an external service which needs to be used by several people, and the organization wants to safely manage the access to the shared account on the external service, adding accountability: who was using the account at X time? Users of the shared external account should not know the credentials of the account, so rotation of passwords when employees leave/change roles is not as necessary. I thought of something like a proxy which could use a Selenium (or something else) script for each of the external website, which would handle the login/authentication flow for the external service.If this was a business, those scripts could be offered as a per-website/month package. An administrator would create the automatic flow for a specific service, and save the username and password somewhere in the script. Normal users of the external service’s singular account would then use the proxy using their individual credentials, to add accountability to accessing the external service. Maybe someone in this realm could come up with something and market it."

I'd say you will need a password manager with good auditing. Give them access to all the required passwords but log every access to it. So if someone leaves the company, you know which passwords to change.

Groups and ACLs would help to give "scoped" access to passwords.

1password.com works well.

A lot of people are recommending 1Password as a password manager. Why is this better than Bitwarden or self hosting Vaultwarden?

I made duckist.com for this. Browser-side encrypted and easy to use. It's the "low-hanging" fruit you're talking about :)

We built https://passpass.co for quick one time password sharing.

Not a full fledge solution but useful for quick one time sharing. Curious if people here find it helpful.

Hashicorp Vault.

I am wondering, where did mTLS and client certificates go. I mean pretty much every app is likely to operate over http, and that’s the base, the defined way to do user authentication.

I know the third party SSO services are recommended but .. I still have a hankering after the old, run it yourself approaches.

Am I missing something?

Best to use SSO for SaaS passwords. This is where your whole team has a Microsoft or Google (or other identity provider) login administered centrally by the company that is further used to authenticate to various services.

As opposed to "login with Facebook etc." logins that are individually administered by each end user for each app.

This is low fruit for many things but often companies require you to be on an expensive SaaS pricing tier to use SSO on their product.

Next problem to solve is Software Engineer's cloud secrets. Use key vaults in your cloud for this. Use SSO to authenticate your team to that cloud.

Enable 2fa as much as possible. TOTP not SMS.

Finally you will need people to save passwords for some stuff. Lastpass or Bitwarden etc.

Avoid shared passwords. Sometimes unavoidable in which case rotate them often and when people leave too.

It's Okta's key feature... Once a user logs in and reaches their 'Apps Dashboard,' they can click on any SaaS app to open it in an already authenticated session without needing to know the passwords. This makes it possible for multiple users to access a single license.

write it on a page and pass on /s

write it on a page an pass on

If you're sharing lots of passwords you are really messing things up. Rethink your approach.

enpass.io

We use Azure Key Vault

Ess Ess Oh. Understand the number of individual warm bodies who need access to what. In an ideal world (that may not exist) this should be aligned to job description/contract and the process for when those people are removed under any circumstance. Pay for the users you need on the platforms you use, whether that's cloud or resources for on-prem/locally managed tools. Elevate legacy systems that aren't implemented for the scale you're operating at to be managed safely on a per-user level. Tell executives/budget process/whatever/whoever these liabilities exist and need to be covered in budget.

And then, yeah, find a password manager tied into that SSO platform to fill the gaps/enforce policies for users using tools that don't have SSO available.

HR-and-manager-enforceable policies and penalties for users who go off the reservations.

1Password for Business

This is a great question IMO. For those saying "just don't share passwords", consider that many of the vendor accounts you might need to use in business don't have team accounts, and there is no option but to share accounts. It's a legitimate thing that comes up rather often.

Use a password manager, like Bitwarden

We use 1Password. It’s not perfect - great for general groups but not when you end up duplicating credentials across different groups that need them.

Would still recommend.

Our team was on lastpass, For some reason closed it down and now using Keeper. So far so good

Echoing a lot of people here but...

Password manager like 1Password, for the few passwords that do need to be managed

SSO as much as possible. Fewer places to manage access = easier onboarding and off boarding

In general you want to use role based access control. I'm not familiar with off the shelf solutions, but the concept is that you grant people access to systems according to what they need for their job (role). A role in this case may be a team, or a specific job on that team (e.g. engineers on xxx product team). Then e.g. when that team has to add another engineer to their oncall rotation, they give them access associated to that role. When person moves off the team access gets removed. when the team realizes they need another permission to troubleshoot their systems, everyone in that role on the team gets it. Etc.

While building Adaptive (https://adaptive.live), I have been working very closely with regulated industries, financial institutions, healthcare orgs. Traditionally, people have been using Cyberark to do Identity management, paired with Privilege access management.

There are some modern Privileged Access Management platforms like Strongdm, teleport, us (https://adaptive.live) and few more in the market that works well with cloud and modern application architectures.

There is debate in the industry whether access should be given or not. There is pros and cons for either of them. This purely depends on the culture of the org in my opinion. But in scenario, you really have to give access, it should have the least privilege as well it should be time bound. Also, all the operations should be audited and recorded.

I believe you should have zero standing access in the org, but there are always use cases like data repair and administration where you have to give access to users. In that scenario, the access should be limit, time bound and audited. Also, you have to make sure you run access review campaigns and checks for over privileged or unused users.

I have Bitwarden Enterprise deployed and authenticate via our IDP. It's been working well for us, each team has their own collection that they manage. From an IT admin perspective, it's pretty hands off. Any changes to password are automatically synced between users.

https://keepass.info and share the database file on a shared folder or sync it somehow.

Recently onboarded my company to 1Password. The password sharing feature is great as is the team vaults.

`pass` https://www.passwordstore.org/ , shared password are shared as long as PGP kays of the participants are in the repository.

Keeper for human-to-human ones that cannot be otherwise managed with individual account access and OpenBao (Vault fork) for automated secret generation and sharing. Implement an IdP (SSO and more) on-prem because it's so much more convenient and safer than outsourcing.

Hashicorp Vault generally linked up to IDp or One Time Secret (or some service with expiring limited use links).

It’s pretty extendable and can integrate with other engineering use cases, shame about hashicorp license change though. Openbao looks great though as a replacement. These are open source so look no further if that’s what you’re looking for if you want password management, ssh auth, cert issuance, authentication and secret retrieval with k8s for example.

We had this problem at my last job - ended up building our own system cause nothing really fit.

Some tips from what we learned: 1. don't use shared spreadsheets or docs, way too easy to mess up 2. need granular access controls + audit logs 3. automate onboarding/offboarding as much as possible 4. rotate creds regularly, especially for sensitive stuff 5. use SSO where you can to minimize password sprawl

There are some decent enterprise password managers out there, but they get pricey fast as you scale. We ended up using a combo of 1password for team passwords + a custom system built on top of vault by hashicorp for machine creds/api keys etc.

One thing that worked well was having "password owners" for each system who were responsible for rotations, access reviews etc. helps distribute the work.

If you want something more turnkey, you might want to check out hoop.dev - does a lot of this stuff out of the box, including automated access reviews, just-in-time access etc.

Whatever you do, just please don't use a shared google doc :)

I love seeing all the amazing solutions, but I’m suspecting some of those are merely saying what they’d want to do instead of what their real answer is, which is slack.

*limitations apply.

i know some places uses 1password or similar, where users can then get access to certain shared passwords

and of course, save their own, which arent shared

Single Sign On (SSO) for all applications as the default. That will do 80%+ of what you want. Thycotic (Delinea) Secret Server for API keys, break-glass accounts, etc. If you have a more granular need for Privileged Access Management (PAM) there are enterprise tools for that. (I don't recommend BeyondTrust; I've heard CyberArk is decent but haven't used it.)

You could do a mid-roll-your-own with Bitwarden commercial, etc., though consider the operational management overhead.

There's a lot of tools you could use for this (I'd personally recommend OpenBao), but in my opinion proper SSO, permission and group management is way more important.

If you make an effort to define granular groups for every team, and role you have in your company it makes the management of access to resources (and not only secrets) a lot easier.

In the example you describe, the newly promoted hire would automatically be added to new groups which will have the right to access the needed Secrets. Similarly, whenever a person leaves your company, simply remove them from the groups they are in and they (almost) immediately loose all access.

It's not a small feat to built, maintain and reconfigure all your tools to use it, but if you do it really pays dividends

Use a payroll or onboarding system that incorporates password management

Rippling's Rpass is a good example of effective implementation.

You can deploy passwords on day 1 based on roles, dept etc.

You can also set passwords to be hidden , not shared etc.

SSO is best practice but this is by far the most effective way for vendor account management.

Oh if you are doing this make sure you have set up group-based SSO.

IMHO better write automation as much possible to rotate passwords firsts. Then remove ability for humans to set passwords (if possible). Your automations should store it vault (for machines) or write to 1Password directly (for humans).

Hi! These are the actual problems that led us to develop Polykey (https://polykey.com) - https://github.com/MatrixAI/Polykey and https://github.com/MatrixAI/Polykey-CLI.

The problem is actually a bit more general than just passwords alone, it's any kind of secret credential like keys, tokens, and certificates that enables authority. Thus the problem is actually about authority management.

Even when SSO is involved, there's always going to be credentials that enable access to various external systems. Especially when autonomous services or apps need to perform actions. Also SSO is very much human-operator centric, and is only suited for tightly-managed centralized systems. Such kinds of centralization is ripe for service downtime if the SSO gateway/portal ever goes down, especially if somehow you hacked the SSO flow into autonomous systems. It becomes a single point of failure.

What are the recommended ways to store and give access to passwords?

If it's just passwords alone, using a cloud password manager is probably fine.

How can a new hire be given access to all required passwords day 1?

Although you can just select a bunch of passwords in your favorite cloud password manager and share them with the new employee account, the challenge is actually scoping their authority, tracking them, and managing change, entropy and sprawl - that's not well managed by password managers yet, because password managers are primarily just the key-value DB CRUD of passwords, they have no awareness of the Source, User and Target of authority. So this is what we are focusing on in Polykey.

And when such new hire gets promoted, how can we give access to the additional passwords they will need?

See previous answer. This requires understanding authority scope, which is best done with some sort of visualisation system.

And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?

See previous answer. This requires automation that integrates with the source of authority and other users of authority. It's a also a deployment problem tying into devops and so on. The key thing to understand is that once you share a secret with them, there's no takebacks. Capability-based security theory does mention ways of dealing with this, such as delegating a proxy derivative authority rather than the true underlying authority.

We're still in development and we're currently working on the enterprise portal as a control plane for addressing the more difficult questions you have. We've got internal documents explaining the theory behind the general problem of authority management, however they haven't been released to the public yet. I will likely publish them on our https://polykey.com/docs soon.

Best fight? Don't be in one.

As many here have recommended, where possible employ authentication/authorization mechanisms which are not reliant upon account+password for everything. OIDC, OAuth2, Kerberos[0], and Active Directory[1] are all technologies worth considering.

Where possible, employ a per-developer sandbox development environment such that each can have a representative system able to support feature/integration tests without having to rely on the CI/CD workflow or a fully replicated production environment.

All of the above share a common theme - limit shared access while maximizing productivity.

As for access to support tools, like source code repositories, ticketing systems, wikis, HR systems, and the like, automate where possible to create the requisite accounts and recommend use of a password manager for same.

EDIT: bonus points for using a private organizational GitHub repo configured to execute GitHub actions that create the above support accounts when a new-hire PR is approved by authorized personnel.

0 - https://en.wikipedia.org/wiki/Kerberos_(protocol)

1 - https://en.wikipedia.org/wiki/Active_Directory

1Password or similar service w/SSO

Just rawdog it on the whiteboard