Ask HN: How to store and share passwords in a company?
We tend to have zillions of passwords in IT jobs right?
What are the recommended ways to store and give access to passwords?
How can a new hire be given access to all required passwords day 1?
And when such new hire gets promoted, how can we give access to the additional passwords they will need?
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?
Any best practices? Any 80/20 suggestions? Low hanging fruits? Any warnings about what not to do?
296 comments
[ 3.4 ms ] story [ 279 ms ] thread2. 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.
Groups and ACLs would help to give "scoped" access to passwords.
Domain registry, password management and SSO are services which can kill your entire company if you lose access. The other option is to deploy your own SSO as a service, but that does run into the issue of potentially running a security critical service without having sufficient chops internally to keep it secure.
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.
You’ll have a similar effect in all password storage solutions, but since adding/removing people from vaults is much simpler, you end up with smaller, more fine-grained vaults and less secrets to rotate. Also, SSO, SCIM, tying the password management into a proper group/authentication system will help.
In a way doesn't this just more directly reflect the reality that anyone you've ever given access to a password may have made a private copy of it? It's not actually safe to leave passwords unrotated when someone who had access to them leaves.
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.
Although I’m not sure why you’d go with a 3rd party idp rather than just using Google Workspace (or Microsoft equivalent).
- 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.
We also use opal for dynamic access to things like AWS or our DB service where a temp user with a specific IAM role / temp db user / pass is created for that user's session. For higher level access, someone would approve the request before credentials are generated.
https://opal.dev/
I think it's unsuitable for SCIM because I'd have to create 5*30 AD groups?
Of course, if there’s a way to simplify the access (like are there truly 5 roles or in practice do people end up bucketed in to 2/3), or if you can configure one role group with the user is always in and group per workspace that’s always ideal, but that might well come back to bite you.
Happy to have a level of group synchronisation out of HR's systems, but certainly would not give them the ability to manage the high-power users.
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).
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.
I don't have much experience with either product but based on what the person said, that seems the most plausible reason to me. If 1Password does something like encrypting it for every user individually and so the server can't read the stored data (like when it's decrypted in the browser with the user's password, then an attacker would again need to compromise the website, wait, and hope nobody notices until their target logs in), then I guess GP really needs to clarify what they meant
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.
For robotic accounts, cloud providers usually even come with a vault solution (Azure keyvault, etc.) that is audited. Those vaults can be integrated in kube/openshift and seen as secrets directly by applications.
For human users, SSO is a must, otherwise a password manager that also gets audited.
PCI-DSS audit would require this kind of things.
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.
When I see how people decide to use this tool, I really wonder if (the current state of the art at least) really is a tool for the good or if it needs big watermarks so it can be rejected when you try to propagate/submit the contents somewhere and it becomes only usable for the things it's good at like summarizing short texts to tweet size or helping with language learning or such
> On-Topic: Anything that good hackers would find interesting.
I find the challenge of sharing passwords within a company extremely interesting.
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.
This is a great best practice, but user-based value metrics for many SaaS platforms make this untenable for some IT departments. If folks have to log in seldomly, it's very hard to make the business case to pay per user.
Similarly, there's many SaaS platforms that charge A LOT extra for SSO because you have to upgrade to their Enterprise-pricing model. If managing a separate user directory isn't worth it because the software isn't personalized, understaffed IT departments aren't going to do that either.
So while there is a best practice, dismissing solutions that are "good enough" (while sharing tradeoffs) isn't as helpful.
A) Who reads those? B) Who cares if e.g. Miro finds out you're sharing accounts and get banned?
You really should change passwords the second they leave. Yes it's a PITA, but you should do it anyway.
In many environments, sharing passwords is never "good enough".
I can setup shared inbox and shared account that all users will have access to.
If we would properly manage configuration for each SaaS app we would have to have full time employee just to do that.
Yes there is SSO and you can setup roles and rights and align that - but let's say you have Joe in CRM SaaS that has customer X - Joe leaves and only he gets notifications, now someone still has to reconfigure CRM so Jane gets the notifications, removing access from Joe is easy. That is why companies get shared inboxes because then you have pool of employees that will check shared inbox and also shared account.
Yes in ideal world Joe does handover of his customers and configurations before he leaves, but we know world is not ideal.
There'll be times that employees can't use SSO though. For that I'll add my voice to 1Password - it's well designed such that a breach of the 1PW service itself won't reveal credentials (you'd need peoples vault passwords and secret keys for that). Avoid Lastpass - the UI is awful, and they've been breached in the past.
They have had multiple serious breaches and to add insult to injury they have engaged in some gaslighting-esque style marketing to inquiries.
BTW, not related to the passwords is to put everything non-public serving behind a firewall and access it only via individual VPN keys.
What risks & attack vectors do you have in mind here? Also, in how far is this an issue with KeePass (whose files are encrypted)?
People with deleted passwords not being able to access the old file, or really any kind of mistake being irreversible.
Backups that you can erase work fine, but version control will create trouble.
* 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.
inserting some line breaks...
* 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.
So the server can read all data or how does this work?
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.
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.
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!