[HN Gopher] Ask HN: How to store and share passwords in a company?
___________________________________________________________________
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?
Author : hu3
Score : 75 points
Date : 2024-09-01 15:17 UTC (7 hours ago)
| re-thc wrote:
| 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.
| Someone wrote:
| And #2 is only to be used if absolutely unavoidable and even
| then, I would think hard about alternatives such as ditching
| the service that would require using that solution.
| michihuber wrote:
| 1password.com works well.
| ioman wrote:
| 1Password has shared vaults, 1Password for Business has the
| concept of groups.
| hellcow wrote:
| The critical missing piece of 1Password for Business is that it
| won't reveal to IT admins what passwords are weak across the
| org (Watchtower only works for the individual). Despite endless
| training, people still choose really weak passwords, and you
| need tools to spot this and require employees to change them.
| drexlspivey wrote:
| Looks like they do have Watchtower for business
| https://support.1password.com/reports/#create-a-business-
| wat...
| micw wrote:
| 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.
| petarb wrote:
| Use SSO when possible and fallback to 1pass vaults when SSO isn't
| possible
| ajb wrote:
| This is the right answer for internal threats, because having
| each employee have their own login to services means there are
| auditable. However it does mean you need to think carefully
| about the SPOF issue (single point of failure). Especially if
| your SSO is Google or some other company with a habit of
| pulling the plug without recourse.
|
| 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.
| theideaofcoffee wrote:
| 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.
| Xylakant wrote:
| We uses D the same approach for a while. Pass/gopass will do
| that for you. However, the downside here is that it quickly
| gets unwieldy as you'll end up with a relatively large vaults.
| And you can't really remove people, they can always keep and
| decrypt old versions of the vault, that means that you do have
| to rotate all of the secrets in that vault manually if someone
| leaves. And then, there's also the support cost for non-tech
| people. GPG on windows is a particular pain.
|
| 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.
| ericalexander0 wrote:
| 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.
| vrosas wrote:
| Next you're gonna tell me "send me the password over slack and
| then delete the message" isn't good password security.
| nolok wrote:
| About 1, unless you have a dev team and dedicated time to make
| compatibility layers, you're more or less limited to whatever
| application and saas supports your sso of choice though,
| correct ?
| cj wrote:
| No, SAML is the standard these days and it's supported nearly
| everywhere (where it matters). No vendor lock-in.
|
| Although I'm not sure why you'd go with a 3rd party idp
| rather than just using Google Workspace (or Microsoft
| equivalent).
| jitl wrote:
| - 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.
| theogravity wrote:
| We use 1Password at our company and it works extremely well.
|
| 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/
| egamirorrim wrote:
| OOI do you ever use SCIM for something really granular? I have
| a service where people can be one of 5 roles and then have
| access to 1..30 named 'workspaces' - all that we'd like to
| control with policy on our side not vendor side
|
| I think it's unsuitable for SCIM because I'd have to create
| 5*30 AD groups?
| icansearch wrote:
| I wouldn't want HR in charge of my secrets management in any
| way shape or form.
|
| 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.
| meerita wrote:
| I love 1Password. I use it personally, but at company level we
| use another.
| serial_dev wrote:
| 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).
| dvh wrote:
| Yellow sticky note on the monitor?
| nutrie wrote:
| Buy_m1lk.
| vinay_ys wrote:
| 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.
| modzu wrote:
| 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
| simonw wrote:
| Asking on Hacker News IS consulting with IT professionals.
| politelemon wrote:
| 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.
| frompdx wrote:
| Why do you disagree 1password is good enough for business?
| dghlsakjg wrote:
| We use Bitwarden as well. It seems to offer the sort of fine
| grained controls that let the right people have access to the
| right secrets.
| ivantop wrote:
| We used 1Password at a ~6,000 employee tech company and it was
| fine. Never had any issues with 1Password.
| simonw wrote:
| What makes Bitwarden better than 1Password for company use?
| lucb1e wrote:
| They mention self-hosted. Unless there's a long-game supply
| chain attack where they infiltrate the vendor and poison the
| updates and nobody notices until it's too late (that disaster
| scenario can always happen), at least not all your passwords
| are gone the minute the central server where everyone's data
| is stored gets compromised
|
| 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
| rr808 wrote:
| 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.
| jiehong wrote:
| Exactly.
|
| 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.
| debarshri wrote:
| 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.
| Koomalater wrote:
| 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?
| sjducb wrote:
| I think stack exchange would delete the question because it is
| too vague and open to opinion.
| Koomalater wrote:
| true, ask chatgpt to reword this post to be appropriate for
| stackexchange first. i cant think of a way to ask this and
| chatgpt failed also. maybe there is a link to a duplicate
| answered q there
| spencerchubb wrote:
| there is no way to word this question to be appropriate for
| stack exchange. it fundamentally does not belong on stack
| exchange
| Koomalater wrote:
| yes I can kind of see that, its not specific enough and
| almost a product recommendation ask. Normally the
| Security department handles this and we turn it over to
| them to make the policies and procedures.
| lucb1e wrote:
| yeah let's waste big LLM energy on obfuscating wording to
| make it sound like your off-topic question is actually
| topical ...
|
| 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
| ale42 wrote:
| And (except on a specific site within their network), product
| recommendations are OT.
| lucb1e wrote:
| I was going to ask if it isn't the other way around, when I
| realized you probably mean off-topic rather than on-topic.
| If anyone ever runs a competition for the worst acronym
| ever, this nominee can probably only be topped by a three-
| way confusion or something that threatens lives!
| simonw wrote:
| https://news.ycombinator.com/newsguidelines.html
|
| > On-Topic: Anything that good hackers would find interesting.
|
| I find the challenge of sharing passwords within a company
| extremely interesting.
| zie wrote:
| > 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.
| healsdata wrote:
| > Yes, but they should be unique to your account. I.e. via SSO.
|
| 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.
| wahnfrieden wrote:
| Shared PWs are sometimes inevitable but then you must rotate
| them every time someone with access leaves the company.
| OneLogin also has a way to minimize handling of the shared
| passwords for auto-logins that depend on shared creds
| from-nibly wrote:
| Is sharing accounts not against the TOS of any user priced
| saas company?
| baxtr wrote:
| We change our PW for some platforms every month, so that
| people leaving won't have access anymore
| gazoakley wrote:
| SSO all the way (if you can). Chances are you've got Google
| Workspace or Microsoft 365 - both allow you to configure SAML
| based SSO into many SaaS apps either through their respective
| app galleries or some kind of custom configuration. Otherwise
| you could look at Okta, but be prepared to fork out serious
| cash. We use Entra ID (part of Microsoft 365) for SSO in our
| business, and it generally works well.
|
| 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.
| ddtaylor wrote:
| > 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.
| siva7 wrote:
| 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.
| lucb1e wrote:
| Well, they're asking how to share them, maybe this is why...
| freefaler wrote:
| 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.
| marcosdumay wrote:
| Don't put in a place where history is saved (as in, don't put
| it in a repo, put on a shared disk). Also, make sure to rotate
| the key when people change.
| codethief wrote:
| > Don't put in a place where history is saved
|
| What risks & attack vectors do you have in mind here? Also,
| in how far is this an issue with KeePass (whose files are
| encrypted)?
| SeanKilleen wrote:
| 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.
| lucb1e wrote:
| > * 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.
|
| 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.
| lucb1e wrote:
| > Easy ability to recover if an employee forgets their master
| PW
|
| So the server can read all data or how does this work?
| feraldidactic wrote:
| 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.
| arandomhuman wrote:
| 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.
| ws66 wrote:
| 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!
| fpoling wrote:
| 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.
| thefz wrote:
| Self hosted Bitwarden instance?
| whirlwin wrote:
| 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)
| rosencrantz wrote:
| 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/
| stevebmark wrote:
| LastPass, Keeper, or 1Password. This is a fully solved problem
| you don't need to ask SO about.
| gazoakley wrote:
| I'd avoid LastPass. The UI is awful, and they've been breached
| before: https://krebsonsecurity.com/2023/09/experts-fear-
| crooks-are-...
| lucb1e wrote:
| 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
| Dibby053 wrote:
| In that sense pass is no different from other password
| managers. What prevents the user of an "online" password
| manager from storing the passwords offline, remembering them,
| or not logging out and reusing cookies? You have to rotate the
| credentials themselves anyway.
| lucb1e wrote:
| Not sure what cookies have to do with it. If we would use a
| system where the client software only obtains the secret that
| the user is asking for, it can later say which credentials
| were accessed and thus need to be rotated when the employee
| leaves. If session cookies are still usable by an employee
| whose account was deleted, that's a vulnerability...
| darkhorn wrote:
| https://keepass.info and share the database file on a shared
| folder or sync it somehow.
| ChrisMarshallNY wrote:
| 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
| lijok wrote:
| +1 for 1password, it just works.
|
| Avoid lastpass like the plague. I can't believe the company is
| still around.
| OutOfHere wrote:
| Never use LastPass even if it works. It has a disturbing
| history with many hacks.
| dataflow wrote:
| > I have heard that LastPass is about as good
|
| I am shocked how you could've possibly heard this. Basically
| everything I've heard rounds to "LastPass is the worst
| available option" and "1Password is the best available option."
| I use neither.
| cbanek wrote:
| Have also used 1password. It's great. It has an API that you
| can code against for automation, and you can also mirror some
| passwords / tokens into hashicorp vault.
| tootie wrote:
| 1Password is the way to go for service accounts shared by
| admins. Not sure if OP is talking about users though. In that
| case, should definitely pick an SSO solution for as many
| services as possible.
| chiefalchemist wrote:
| The fanbase for LastPass on HN is close to zero.
|
| Bitwarden paid allows for sharing folders out to other users. I
| believe those can be non-paid.
|
| Various clients have used 1PW. It works but for reasons I don't
| recall atm I never liked it as much as BW.
| greenthrow wrote:
| If you're sharing lots of passwords you are really messing things
| up. Rethink your approach.
| etaioinshrdlu wrote:
| 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.
| prettyStandard wrote:
| It's a fork and refactor of another comparison of password
| manager software I found.
|
| https://password-manager.soft-wa.re
| system2 wrote:
| KeePass in enterprise form with Pleasant Password Server.
| Supports many things including SSO. Of course it is local.
| dlm24 wrote:
| Our team was on lastpass, For some reason closed it down and now
| using Keeper. So far so good
| xvdAZh wrote:
| (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)!
| tester756 wrote:
| Microsoft's Active Directory either managed or self hosted and
| you'll have SSO
| fyt2024 wrote:
| enpass.io
| FrozenCow wrote:
| 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.
| tmnvix wrote:
| Thanks for this comment. I currently use direnv with great
| success for managing virtual environments (mostly various
| language versions, dependencies, and environment variables).
| I'll look into this approach of pulling in credentials for
| those environments from a password store.
|
| I think direnv is a highly underrated tool. Switching between
| environments with a simple 'cd' is of huge benefit to my
| development experience.
| JanMa wrote:
| 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
| davemtl wrote:
| 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.
| protocolture wrote:
| 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.
| progmetaldev wrote:
| 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.
| langcss wrote:
| 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.
| TheSaifurRahman wrote:
| You might want to take a look at Infisical
| (https://infisical.com)
| sgloutnikov wrote:
| 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
| tptacek wrote:
| 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.
| karmakaze wrote:
| 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.
| worldsayshi wrote:
| I agree with this. But I want to ask a similar question as OP
| but for services. How do you handle service account credentials
| in a good way? Typically multiple engineers need to be able to
| test out a given service account. So a number of users need to
| have access to the credentials of that service account. And you
| need a good way to enroll a new service to service connection,
| i.e give a service account access to another service.
|
| I haven't seen this done in a way that didn't feel overly
| complex, prone to error and oversharing of secrets.
| karmakaze wrote:
| > _the credentials_ of that service account
|
| Why do these accounts only have a single user/password?
|
| In any case, my answer would again be automation. Script the
| test, have the authorized process test out the service
| account on behalf of any employee who can create and run
| those tests.
| betaby wrote:
| `pass` https://www.passwordstore.org/ , shared password are
| shared as long as PGP kays of the participants are in the
| repository.
___________________________________________________________________
(page generated 2024-09-01 23:00 UTC)