Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to store and share passwords in a company?
316 points by hu3 3 months ago | hide | past | favorite | 277 comments
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?




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.


That is the answer.

SSO, then password manager.

I'd strongly recommend bitwarden, having deployed and managed it. I would warn against lastpass, strongly, due to papercut level issues everywhere. I haven't used 1password in an appropriate scenario to comment on it.


> LastPass

There was the time they lost customer data in a hack and then lots of customers data was exploited. https://en.m.wikipedia.org/wiki/LastPass


I’m still suffering from this; somehow in this hack <<something>> happened to my LastPass account and login/unlocking it became impossible. LastPass support (rightly) can’t help, so 3 or so years later I’m still stumbling into sites that I can no longer access.

Many sites have forgotten password flows, they’re easy, but many other sites related to municipal services, etc, require hours on calls, often on hold, proving my identity and getting access reinstated.


The thing about the LastPass Wikipedia article is that someone keeps editing it to reduce the number of really bad security issues LastPass has had over the years. You can Google almost any year, along with "lastpass security incident" and get results.

Nobody with the goal of security should be using LastPass. Nobody.


Not once but multiple breaches.

Just no.


I'm surprised they still exist.


We have SSO + 2FA in place, and would like to use Bitwarden for the rest of the password management. But for a company around ~50 people, the pricing feels too expensive, considering the only purpose is to manage a few passwords. So for now we are using Keepass which is kind of painful, but free. We would probably be willing to pay ~2$ per user per month, but instead it is 6$ if you want Bitwarden to work integrated with your SSO which means 3600$ per year.


Pricing is truly annoying with password managers. I know this is an edge case but I volunteered for my kid’s school PTA and discovered to my horror that all the passwords were stored in a single Google Sheet. But the pricing for the number of users we were looking at (a very small core number of staff but a large number of volunteer parents) made pretty much every password manager service unaffordable, even with non profit discounts. Per seat pricing doesn’t work out for everyone.

We ended up using Dashlane because its free tier allows sharing between users but the administration is so much more work than it needs to be.


Hi! could you please explain what is this admin work that is bothering you? Thanks! (working at Dashlane, and happy to forward feedback to product team. I'll already forward your comment on pricing)


It’s not really your fault, it’s us bending your free tier into something it isn’t intended to be. Maximum number of passwords shared, only logging in to one device at a time etc.

It’s a really weird edge case but eye opening for me as someone who is usually in a very well resourced tech environment. Google offers a great free tier for non profits and in the ideal world we’d have a password manager that plugs into our Google organization without a second thought. But that’s a premium tier feature and any money not spent on enriching the kids education has to be justified to the nth degree. We have people who are go-tos for a two factor auth code because their phone numbers are the ones attached to the accounts… people will go to surprising lengths!

There isn’t a good business case for it as such but volunteer organizations (as opposed to well resourced non profits) would make good use of a free tier and it would generate goodwill with people who are sometimes responsible for purchasing decisions in their day jobs.


You could self-host bitwarden on a $5 a month instance (or free-forever, if you choose to trust oracle or gcp), and then put TOTP 2fa into your bitwarden instance. Still requires a little maintenance on the instance, but this can be 99% automated.


Yeah, the thought has occurred to me. But I’m only going to be there for a few years, the responsible thing is to do something that’ll survive long after I’m gone.


I've volunteered for and served on the boards of several small, youth-oriented nonprofits. They all had this weird idea that you can't spend any money on operational stuff. Yeah I get that you want to minimize it, and you should. But payments for necessary services should just be part of the budget. There is overhead to running these orgs and not every penny can go straight through to the kids. If you make things a PITA for the volunteers, eventually you won't have any volunteers. People are giving their time freely to help, but most are busy and don't want to f*ck around with complicated solutions that waste that time.


A strength that is often overlooked at NGO's is their people power, so don't forget to leverage that. For instance, cctv, each unit, each chief and his 4 indians, could simply use wyze to monitor their immediate environment, worst case scenario, the chief leaves in a bad way and someone else has to reprogram the wyze cams to a new chief. Same with passwords, if you don't want to pay for centralized admin, then create multiple self-sufficient micro-environments with one central IT as tier 2 for advise and rescue. Think of it as vlans, but in admin terms. This method, opens up a lot of free tiers out there for each tribe/unit to leverage, as long as IT/CENTRAL, get's informed of the master-pwd (ex. bitwarden etc.).


Completely agree. The kind of people I've encountered in non-profits and charities as an IT Sales Professional over 20 years is that they expect great products and services should be as close to free as possible. They don't seem to understand that the tax breaks and incentives are there precisely to help soften the costs of running such an organisation. To expect even MORE than that from vendors is unrealistic. I watched an interview with Naveen Jain (Viome CEO) on a podcast once and he said that a non-profit entrepreneur or CEO is more often than not "just a sh*tty entrepreneur". I couldn't agree more based on my experience selling tech since 2001!


Oh, I totally agree. But I’m in the minority in that view and have come to accept that it’s just the nature of the beast.


Why not just use something like Keepass in this scenario for free (forever) ?


I know very little about PTAs, but... why would a PTA need to share passwords anyways, instead of having separate logins?


Immediate example that comes to mind: there’s a paid-for Canva account that multiple people need to use. Can’t use separate logins because then you’d need multiple subscriptions.


This is in breach of the tos though, right? Great example to set for the kids.


Moral argument is that a PTA are part time organizations and if canva doesn't cater to that business model, then shared credentials is fair use, commercial and for profit use is a horse of a different color.


Pretty sure the kids aren’t aware of the PTA’s use of Canva.


Why not self-host Vaultwarden? It implements most functionality and supports the standard Bitwarden clients with virtually no resource requirements.


Was going to suggest the same, of course you're taking matters into your own hands, so know what you are doing, but it's free, very light weight and supports "organizations" as a way of sharing passwords between people. I have hosted it for my family for years and was very happy with it (until I switched to Proton Family, now doing ProtonPass).

And you get all the excellent Bitwarden apps and extensions to go with it.


You trust Proton with that data?


I certainly do, I have not seen anything yet that makes me reconsider. They have always answered to concerns well. They pass security audits.

Sure I'd prefer a Linux Proton Drive client over a BTC wallet, but nobody's perfect.


> I have not seen anything yet that makes me reconsider

Proton will pwn you if Interpol smiles at them the right way. This is common knowledge.


These is non-sense. They do not do anything more or less than any company does, they do not have access to decrypted data (so they cannot share it and havent done so obviously), and I bet in most of the discussion here interpol is not in people's threat models.


That is indeed bs. They gave up some IP addresses in accordance with local laws.

Why are you saying this? To justify your own use of free big tech services at the cost of all your data? Proton services have been audited, Proton staff cannot access your encrypted data. Whereas we know from Snowden et al that your data in most public clouds is readily available to the world police. Make a pic of your kid's private parts for medical reasons and people have found out the difference. My pictures are encrypt before they go to Proton Drive.

If Apple starts on-device scanning to see if I'm a criminal while I sleep, I'll be on GrapheneOS several days later, but still a happy Proton user.


I'm not making a claim that FAAANG is any better. I'm just saying that when FVEY wants your data and you've opted for convenience over security, you WILL be owned. It's not so much that Proton is untrustworthy, it's that they operate a business, and if the pigs tell them to make exceptions to their policy for your account, it's game over for you. Proton doesn't have the balls that Ladar Levison did with Lavabit. They won't shut down for you, they will hand you over on a silver platter for the pigs to pick away at your flesh.

Don't use any external service hosted in a country that complies with LEO or MLAT requests from the country of your residence. Actively seek out services hosted in countries that are hostile to the country of your residence.

Host your own infra, with your own authenticated FDE, reed switches and shock sensors for instant power-down on the cabinet, tamper-resistant and tamper-evident everything. Tor Hidden Services and i2p eepsites for any and all private correspondence if you really take this seriously.


I'll look into it, thanks!


Ever tried Psono? (I am Sascha, the main developer behind it)

It has SSO / encryption / self hosting / ... and even the enterprise version is free for up to 10 users and if you need more you only pay €2.5 / user / month.


Passkey support (I know it's a pain) would be great...


Use Vaultwarden then


I'll check it out, thanks!


We went with self-hosted Passbolt. Free, open source, and based on PGP. Only downside is having to explain PGP to the less technical users...


This is really a HUGE hurdle. Sadly even many developers don't understand it fully / mess it up a few times..


We use passbolt too, I'm not sure I ever had to mess with pgp once.

It seems to work well / just works.


Except the search function of bitwarden is totally broken. Searching for A B shows everything with A or B, not even with A and B at the top.


There is a syntax you can use to search for entries that contain both A and B:

>+A +B

It is annoying but it works.


This could be a good first contribution to Bitwarden for me or anyone really.

Do you mean the browser extension search feature?

Thanks for pointing it out.


Just checked, and its indeed doing this nonsense in the browser extension (on firefox). Its implemented sensibly in the Android app, and I haven't tested the website vault viewer or the desktop app.


Thank you for checking and reporting back.

I never touched Bitwarden project but I hope I or someone could contribute to a better search in the extension.


I was first using 1Password and then I really tried to love Bitwarden for two entire years (paid user). But it was riddled with bugs and UX mishaps. I gave them detailed feedback by email, they acknowledged it, but nothing changed and my frustration grew over time. I eventually switched back to 1Password one year ago and I'm delighted.

For example here some issues I flagged to the team. Note that some of them may possibly have been resolved since then:

– The “incorrect ciphers” error that keeps happening where you have to restart Bitwarden and lose all your changes.

– Basic searches take multiple seconds if you have more than 400 entries.

– Editing items is awkward. Whenever I scroll down an item and want to edit a specific entry, I have to find the edit button and then WOOSH a new panel appears and I don’t know where the field I wanted to edit ended up in the new panel.

– Bitwarden doesn’t automatically categorize login items by type and it's not possible to exclude items from the “All Items” list. So it's a big mess and when you try to search a massive amount of irrelevant auto-generated entries pop up.

– Scrolling is super laggy on Android.

– Android logins don't have icons (they could very easily extract them when Bitwarden automatically creates an entry when logging on an Android app).

– Phone numbers are not formatted. Same for many other data types.

– Credit/debit cards show a generic icon rather than Mastercard, Visa, American Express, etc.

– The whole interface is marked as selectable in CSS and when you try to move the window around it keeps selecting irrelevant text from the UI such as “Search Vault” and “Item Information” instead of moving the window. Likewise, if I try to select actual text the selection isn't constrained to the field I'm selecting from so I often select a bunch of crap I didn't mean to select.

– Clicking on a password field doesn't offer the option to generate a password.

– Password generation settings don't synchronize between Bitwarden instances. Every time you install the app or the browser extension you have to reconfigure the length, symbols, letters, casing, etc. Again. By default it uses Bitwarden's default basic (and pretty insecure) criteria.

– Bitwarden frequently doesn't detect password fields, and frequently doesn't offer to automatically save the password.

– Can’t drag & drop an item from the list to a folder. I have to manually edit the item entry and select the folder from the dropdown. Every time.

– When editing an item, the ‶Attachments″ entry is a tiny line hidden below ‶Master password re-prompt″ so it's incredibly easy to miss and hard to find.

– Attachments don’t have previews and you can't rename them. You have to manually download a given item and open it in order to see what it's about.

– Can't copy attached images to the clipboard. Instead you have to press the download button, pick a folder, find it, copy the file (or possibly open it with an image editor when you need to copy the image itself), and then paste it where you want.

– Automatic entry names are dumb. For example for Android apps it just picks the package name (e.g. com.voyagerx.scanner) instead of the name of the app (in this example the corresponding app's name is vFlat, so not clear from the package name!).

And this is only the tip of the iceberg. I had many more issues than those with Bitwarden. None of these issues happen on 1Password.


Thanks for spending the time on that list. Hopefully Bitwarden will see this and reprioritize there game plan. You cant have a solid password manager without these things working. I have been using Keepass for years, but was thinking about switch to another product in the future, but I think I am going to stay with Keepass.


And when you set up 1Password, make sure you also get the CLI going, so passwords & shared gunk that's needed to access other people's services can be scripted, and when the passwords, etc get rotated no-one needs to know because no-one needs to store them.


[flagged]


You're going to have to elaborate. I've been using 1pw for about 7 years, including at several startups where I've handled IT. It has worked really well, yet to be breached, has a CLI, handles passkeys and SSH keys, easily separates work and personal creds, and their support is fantastic.

What specifically is terrible?


People are still upset from when it went from a mac native user focused app to a subscription based multi-platform enterprise focused app.


It's actually not and is arguably the leader in password managers. Full stop. You should elaborate your future comments a bit more.


I can't imagine what you'd have to have experienced to recommend Keeper over 1Password


Unfortunately the SSO tax isn’t the worst. Most companies pay for it anyway.

In my experience (as in IC), the real issue is when the company don’t want to pay enough seats for everyone.

Honestly sometimes it makes sense when you don’t use the tool everyday but it’s a PITA.

I think, maybe, that SaaS companies should reflect on a (capped) per-day billing for those accounts.


On top of this, prefer individual accounts and passwords over shared accounts.

Some services require shared passwords, keys, or tokens. Consider grouping them by sensitivity. Key to the kingdom shared accounts should be accessible only to a tiny number of people.

Finally, never send credentials over plaintext, such as email or Slack. 1Password and other password managers have a “share” feature. If need be, send a zipped and encrypted text file and share the password via a voice call.


>If need be, send a zipped and encrypted text file and share the password via a voice call.

Because people are lazy and not everyone wants to write a file, zip it, encrypt it, call someone, spell the password... Consider sending the password regularly over slack, wait a minute till the other side confirms they got it, and remove the message.

Mediocre solutions that people use are better than perfect solutions that everyone circumvents.


> never send credentials over plaintext, such as email or Slack

Slack works for us in a very small (<5) number of trusted long-time remote devs, but with two important conditions:

1. New/updated password(s) to be shared are in an encrypted Keypass file (encrypted with a preset and prearranged password that was only shared once offline). Recipient merges into their local keypass file.

2. Confirm recipient is online, send, confirm receipt, delete immediately afterwords.

We use many AWS services so obv all those are handled with AWS Secrets and IAM, so we only need to save the login pwd externally. And for services which support multi-user, Google, GitHub, etc., each user has their own pwd. So not many passwords need to be shared in the above manner. In daily use I keep KeyPass open and copy/paste passwords into the browser when needed -- nothing stored online.


1Password is brilliant. They have all sorts of open source libraries and integrations on GitHub.


1password is solid, and works everywhere and in most situations. Features are however quite limited on the more basic packages


Never pay the "SSO tax" by outsourcing to Okta, etc. There many FOSS IdP solutions that are usable with some customization and integration.


The SSO tax is the premium your vendors add to accounts that link with any IdP.


FOSS solutions like Keycloak are absolutely capable but it completely ignores the "tax" you pay in terms of maintenance and setup. For smaller teams, it's not feasible at all to keep something like that up-to-date and running smoothly (i.e. no downtime)


Agree. The trio of Okta + Bitwarden + AWS Secrets Manager covers most bases and has served us well.

The SSO tax is real though, especially if you're a < 50 person entity and don't need everything else that normally comes with "Enterprise" plans <sigh>. Shout out to the few enlightened/kind SaaS peeps that don't do this (e.g. Windmill.dev) !


Consider updating https://sso.tax/


Or better ssotax.org which is already way ahead.


You can even avoid using passwords altogether by using hardware security keys.


What’s SSO and how do I put vendor API keys into it? Like one of the most important APIs we have is just 1 key and that’s it. I don’t think the vendor has heard the term “key rotation”


I would recommend you get some people with IT security knowledge on board, either permanently or at least to do a review.


For API keys you want to look into secrets management, for example Hashicorp Vault or OpenBao. AWS/Azure/Google Cloud also have their own secrets management features.


> 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.


> 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.


Not only user-based value metrics - but also SaaS apps don't implement collaboration in approachable ways for groups.

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's A LOT of good advice for SaaS companies here. The problem e.g. you desribe is clearly something thats solvable on the SaaS side.


Is sharing accounts not against the TOS of any user priced saas company?


Probably but IRL:

A) Who reads those? B) Who cares if e.g. Miro finds out you're sharing accounts and get banned?


we inquired about this to grafana.net, and their reply didn't forbid sharing accounts


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


> So while there is a best practice, dismissing solutions that are "good enough" (while sharing tradeoffs) isn't as helpful.

In many environments, sharing passwords is never "good enough".


We change our PW for some platforms every month, so that people leaving won’t have access anymore


Well except for the period of time between them quitting and the new month rolls around.

You really should change passwords the second they leave. Yes it's a PITA, but you should do it anyway.


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.


> 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.


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.


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.


You need to be able to automate 3 things:

   1. Account pass retrieval
   2. Account pass rotation
   3. Account pass ref update
(1) is how a user gets the pass when needed (normal process or break glass debug). (2) is how the pass rotates to an unknown value, automatically, after the user is done with it. (3) is how the new value gets updated in references, without the user knowing the new value.

At the root of any solution are answers to those 3 needs.


The best way to handle service accounts is nobody knows the password. When X needs to troubleshoot, they change the password, do what needs to be done, then change it again afterwards, to some unknown value.

It's a lot easier if you automate the password delivery to the service account. 1Password can do this with their CLI offering and Vault/OpenBAO can also do this. There are other password managers that can do similar things as well.

With Vault/OpenBAO, for many services, it can handle password rotation and can even generate accounts(with appropriate permissions) for you, so you need access to Y service, Vault will create a temporary account. When the token expires, it will delete the account automatically.

If you can't get there yet, then you limit the damage by limiting the shared password to a small set of people, use a password manager and as soon as any one of them leave the group, rotate the password.


> The best way to handle service accounts is nobody knows the password. When X needs to troubleshoot, they change the password, do what needs to be done, then change it again afterwards, to some unknown value.

one way i've seen this is on a 'lease' system: your user requests access to use the account, the system logs your request and generates a random password for you, you log in and use the account for the duration of the lease, and let the system handle the rest


Yup, that's basically how Vault/Bao does it.


> 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.


Because that's just how some products are set up. Not every external service account provides separate passwords for different employees, there's just a single corporate account that some certain number of people need to have access to.

And automation isn't an answer to that. The question is how to share the password in the first place, not to automate what is done with it.


I've bumped into this with various API integrations to e.g. warehousing systems, ERPs, hosting providers and what not. The advice in this thread works great until you are on a project to integrate X API into Y project, and you need the admin dashboard. Now you have three developers who all need to share one account.


> How do you handle service account credentials in a good way?

Passwordless. If someone can log into a service account then it's not secure.

If you need direct access to systems then you grant temporary rights to individual users. To make this smooth you need to create a service to do it. Basically the flow would be for a user to request access and for the service to ask their direct manager (or whoever has the rights) for permission.

I know it's common for organisations to let IT operations handle this, but this is a terrible practice. Your IT department will almost never be in a position where they are the ones who have authority to grant access to anything without manager permission, a permission they should basically ask for every time. Also it's a massive waste of time for everyone. Yes, I know it's extremely common to just let IT operations do it anyway, but well, you shouldn't.


Unfortunately, some services don’t allow this.


Ideally they would support SSO, but at a minimum any service that wants business customers will have accounts in some form. If they don't even have that then I would seriously second guess using them for anything in production. They're clearly not designed for businesses and can't be relied upon to not screw you up in serious ways.


> but at a minimum any service that wants business customers will have accounts in some form.

I mean, that's just not true. Plenty of successful and widely used businesses out there provide a single account/password for their service at a client company, rather than for each human user at that client company. It's a common pattern even if you think it shouldn't be. And yes they are designed for businsses and have business customers.

For a lot of products, it's just not conceptually necessary to have multiple users for an account, i.e. support for "teams". It's a convenience that might be on the roadmap and might get done eventually, or not at all. Especially because supporting complex sets of user credentials can be a major project, which means another important feature doesn't get done instead.


> And yes they are designed for businsses and have business customers.

What I'm saying is that by definition these aren't designed for businesses. They might have business customers, they might even think that that's where their primary market is, but they're not designed for businesses if they use an account model that is designed for single consumer. And if they can't have been bothered to put together an account system then what else didn't they bother doing?

I'm not buying the idea that an account system is just too complicated and would eat up too much time. There are only a few extra moving parts (teams, very basic roles) for an enormous quality of life improvement for the company (this entire thread would be largely unnecessary if every product a business used supported at least basic account management).


I think your definition is too rigid and unrealistic.

While this example is cherry picked, it’s practical and real world.

A studio is working on a project for a client. They want to share the work with the client. Setting up individual client accounts is both impractical and unnecessary. They instead opt for a single password to protect the project. This password is stored and shared by the client.


Eh, I have a hard time even granting this one exception. The problem is turnover—a single password is fine when it's an individual who purchased the software. As soon as it's a company a shared password becomes untenable because people who are not intrinsically part of the company will need to know the password, and those people can and do leave. The only safe way to handle this is to reset your password every time someone leaves, and that's not scalable for any business with more than a dozen people and a dozen vendors.

In your example, what path forward makes sense would depend on the project, but "single shared password" would be unsatisfactory to me as a client.


> I'm not buying the idea that an account system is just too complicated and would eat up too much time.

Then why do you think there are all of these systems that don't have it? The CEO's/PM's aren't entirely stupid. They know what business customers are asking for, and what they're prioritizing in their asks, and how they're voting with their dollars.

An account system is often going to come with different roles like admin, user, viewer, and then the entire product has to be overhauled to create display-only versions of what were workspaces where changes could be made, new role authentication checks on every API call and even every data operation, and so forth. It can actually be a relatively huge undertaking that winds up touching a majority of the code, that also adds to the scope of most future feature development in a non-trivial way. It's not just a table of users and passwords per account.

I'm not saying it can't or shouldn't be done. I am saying that the idea that a companies without it "by definition aren't designed for businesses" is wrong, though. Not by definition, but by the reality of actual businesses today.


- 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 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.


HR might be a more suitable place to decide who is in what role than IT is, though?


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/


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?


Honestly I’ve worked in places with many 1000s of AD groups. At some point, that’s just what fine grained access control means, I’m not sure there’s much point in trying to prematurely optimise for fewer 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.


Users can be in more than one group right? Or they might have a different role per workspace?


I love 1Password. I use it personally, but at company level we use another.


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.


Okta is inexpensive for small companies (our bill for 200+ employees is like, $3000 a year; it's a couple bucks per user per month). You can use Okta as a password manager as well - just add a new "application" and pick the choice for "shared username and password", which basically makes Okta's browser extension just autofill the password for the user. Works great for sites that don't have SSO as an option.


Next you’re gonna tell me “send me the password over slack and then delete the message” isn’t good password security.


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 ?


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).


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?”


Are they engineers if they appeal to emotions when evaluating risk ?


Maybe you joke but absolutely. Good security is about empathizing with the users and knowing the risk model of the organization and finding a balance of security + best possible UX.


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.


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/


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.


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.


We used 1Password at a ~6,000 employee tech company and it was fine. Never had any issues with 1Password.


Why do you disagree 1password is good enough for business?


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.


What makes Bitwarden better than 1Password for company use?


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


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


> 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.


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.


More specifically, for OP's small business / company question ...

Start here: https://1password.com/product/teams-small-business-password-...

Fix your SSH logins here: https://developer.1password.com/docs/ssh

Then, go here to use from CLI: https://developer.1password.com/docs/cli/get-started/

Explore more advanced options like service accounts: https://developer.1password.com/docs/service-accounts

Or other integrations: https://developer.1password.com/docs/integrations/


+1 for 1password, it just works.

Avoid lastpass like the plague. I can’t believe the company is still around.


Never use LastPass even if it works. It has a disturbing history with many hacks.


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.


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.


My last company settled on LastPass before they gave away all your passwords.


Well, the subject was about how to share passwords. LastPass is astoundingly good at that part.


True; then again, the password stops being a password when it becomes publicly known - if only because some random scammer will change it to a different one and sell the account on black market.


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...


SSO + 2FA is more secure in practice than letting people create/manage their own accounts at every service. Because:

- You can force a password policy centrally (minimum 12 char + uppercase/lowercase + number etc), for every service the company is using that supports SSO.

- You can force 2FA, again for every service the company is using that supports SSO.

- You can disable an account immediately from the central admin panel as soon as you notice an account is stolen.

- When the employee leaves the company, you can delete their account centrally from every service, so there are no inactive company accounts registered to various services.


Yes good points.

I have to argue the second part of this though

> minimum 12 char + uppercase/lowercase + number

The first minimum char counts rule is great. You increase the entropy exponentially with every added char.

But the second part when you make rules about each individual char, then you are actually decreasing entropy. The space of possibilities actually shrinks every time a rule defines what a char must or mustn't be. An attacker now knows that certain things are guaranteed, and can tune their brute force algorithm to expect a big ascii letter, a large ascii letter, a latin number, an ascii special char. They now have a much smaller search space than before, when each char could be any utf8 char. You're basically leaking exploitable information about the password by having character rules.


The alternative in practice is not all utf8 characters, the alternative is lowercase letters. If there are no rules that require uppercase and alphanumerics, or length, then many people will use passwords that are easy to type, and short, and not impose security difficulties on themselves. The alphanumerics + case rule is addressing human behavior, and effectively does increase the search space (by a lot) for most people, not decrease it. It would be nice if most password entries could detect other utf8 chars and allow them to substitute for cased alphanumerics, or if longer passwords could relax the rules. The point is to meet a threshold of security against attackers, and the blanket rule does that but ignores some viable and convenient alternatives.


You also decrease entropy by having a minimum length rule. The point of these rules is only to forbid weak passwords.


> - You can force 2FA, again for every service the company is using that supports SSO.

This can also be a way to balance security and user convenience, which should not be underestimated.

If a user has to do the MFA dance (Duo Pushes, TOTP tokens, ...) once a day for a dozen different services, users will rightfully riot and start looking for workarounds of questionable security. On the other hand, you could have one MFA dance in the morning to get your keycloak session, it is kept alive by normal usage and then it doesn't bother you anymore for the day. Much lower friction.

Another thing is auditing and analysis. With central logins, you need one service with good audit logging, and you need to understand and alert on one log if a user suddenly tries to login from another continent, hundreds of times a minute. Some of these services have this built-in.


While the single point of failure (especially for browser cookies) can be an issue, handing authentication and associated bookkeeping to an entity that does that, instead of plugging your own essentially least viable product level auth on top of every service is a win.

If everyone did authentication well, then centralized IDPs might be questionable from a computer security perspective. But most aren't doing it well.

On top of that, humans generally work best if they don't have to remember lots of truly random passwords. I.e. in realistic settings, there's a maximum of expected passwords either way. And the true gain of having dedicated auth everywhere is minor.

There's some consideration for things like FIDO/WebAuthn/PassKeys, but they mostly just shift the issue from a single provider in cloud, to a single (hardware) token. Harder to copy than browser cookies, but still a single point unless it's combined with MFA.


With SSO, the party running the SSO decides what the authentication policy is.

For example, where the authentication request is coming from (on-site, managed device), what methods are being used (hardware second factor, Authenticator app).

These are all things that the SSO can check at time of authentication, before a token or session key gets issued to the user. Also, all of these things can be checked again when doing any auth flows for the various linked services.

So with stolen SSO credentials, they might be worth diddly squat to you if you didn’t think to also be on-site or on a managed company device (physically or virtually).


Sure, password managers are a SPoF, but in the event of a keylogger installed on the computer of someone with elevated access, you're screwed either way, password manager or not. Still, here password manager + 2FA could have helped, unless... 2FA recovery codes went through the clipboard at a time when the keylogger was watching the system clipboard... Next time I activate 2FA, I'm writing that down, in the dark, in a restroom, fold it, put it in a safe.


Generally people have a recovery option (“Forgot Password”) which routes to the same email, meaning it’s effectively already a single point of failure.

But it’s generally a well-secured one (2fa, ip monitoring ). So in effect we’re not making it more of a single point of failure, we’re just removing the various other means of attack by removing site-specific identities (passwords)


Always use 2fa with sso. You can also use client certificates with sso so only managed devices can use it.


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).


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.


This setup is absolutely the ideal. Sadly it doesn’t often survive first contact with reality.

Bob in sales will sign up for a tool that suddenly becomes load bearing, and it doesn’t support SSO without a 10x increase in the monthly fee. A million dollar client needs you to integrate with one of their services which only supports a single shared API key. And so on.

You also have to consider whether doing the heavy lifting required to get to this point is really the highest priority for your one man company which is yet to make a single penny and has no customers. What you describe is certainly much easier to implement early on when you’re not dealing with a ton of legacy services, but it will still probably take a few weeks of work to make it reliable for everything.


This setup strongly describes how the process was inside Amazon.


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.


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!


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.


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.


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)


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 :)


Bit of a sneaky self promotion tbh but I'll allow it. Just making it clear.


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.


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.


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.


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


I was a bit surprised to not see Infisical mentioned more often.


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.


If you're in a one-man or couple company, then a password manager is enough, eg. 1Password, Bitwarden, or Vaultwarden.

But when your employees start to join and out, the first thing is SSO, IAM & IGA. With strong password requirements, schedule rotation, and MFA. All employees can be onboarded on day one and lost permission on the last day. Then how does an employee on day one know the init credential, you can share the init password with the employee in the onboarding email or face-to-face. The RBAC or ABAC control relies on IAM. The employee lifecycle management and approval can rely on IGA. After this, the milestone for supporting the employee's identity lifecycle is done.

Currently, You have an empty app dashboard. When you start onboarding applications, most mature 2B applications will easily integrate. Eventually, you need to onboard some applications that only support credentials login. This time you need password injection, eg. the password-based SSO on Microsoft Entra ID. Or root or breaking class accounts in the application cannot be integrated with the SSO system, You need to find a new tool, which is PAM. eg. CyberArk, or Hashicorp Boundry. Which can protect those privileged accounts.

In the end, Just do remember, never directly share credentials with your employees, except the init password for your SSO, human error always exists in the real world, people always forget to change the password after an employee or manager leaves or switches positions, and they will assume that person is a good guy, no worry for no rotation.


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


Self hosted Bitwarden instance?


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.


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


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.


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.


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


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.


For online password managers it requires bad intent from the employee and manual work. For pass it's normal practice that everyone has a copy of the whole store.

However, in reality the difference is probably marginal: The majority of the (ex-)employees has no bad intent and couldn't care less about old company stuff once they leave or change roles. Those who plan to do something bad, will also keep copies of passwords from an online system.

To be safe you must rotate once someone leaves or trust your firewall.

pass supports different access in different parts of the repo, just use different .gpg-id files. But the whole system is kind of geeky. If you employ others than hackers familiar with the command line, gpg and git, it's not really an option.


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...


Strong disagree - I use pass and I love it. I switched from keepass and not looking back.

I guess it's for personal use, never tried using it in a company.


Sure, I see what you like about it for personal use: nearly all downsides we ran into are sharing-related


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


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.


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.


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.


> 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.

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.


Absolutely. My point is that pass/gopass in practice lead to larger vaults, so.you need to rotate more passwords. And more advanced password managers offer assistance for that task, which the more basic ones do not.


I use a similar flow with the technical team to avoid unencrypted credentials in SCM. The vault (or other secrets) are encrypted with a common passphrase and then only this passphrase is whats encrypted with GPG for multiple recipients.


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.


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.


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 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.


Same - my last couple of companies have used Thycotic/Delinea (self-hosted) and it seems fine from a user perspective.

For a small company you could probably use self-hosted Bitwarden - I use that for my family but I imagine it'd get pretty annoying after a certain number of users.


Yellow sticky note on the monitor?


Buy_m1lk.


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.


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.


> 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)?


> What risks & attack vectors do you have in mind here?

People with deleted passwords not being able to access the old file, or really any kind of mistake being irreversible.


I'm afraid I'm still not following. Isn't the point of having a history precisely to be able to roll back in case of mistakes?


You don't want a rigid history on the case of some mistake exposing the data. (Like a weak password.)

Backups that you can erase work fine, but version control will create trouble.


Yeah, rotating the passwords when there is a possibility of a leak would be mandatory of course. (As it should be anyway.)


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.


Well, they're asking how to share them, maybe this is why...


ah, so one should ensure that the account is duplicated in some way. "shared", if you will.


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.


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.


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.


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.


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


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.


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.


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.


We also use Keeper via SSO. We had Lastpass before and switched for obvious (breach of their vault) reasons. It's OK? It does its job.


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.


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


Don't mean to sound aggressive, but no professional organization worth its salt does systematic password sharing of any kind. Password sharing is almost always a security violation and, even if shared securely, can generate licensing complications for the product or service you're authenticating into. Better to have one account per service per person who's going to use it and systematically revoke licenses/accounts that go unused. Also use official methods for resetting passwords (email link, TOTP generated by the app itself from an admin console) rather than sharing passwords.

Lastly, of course like everyone said: SSO is your friend!


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.


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


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


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.


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).


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.


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


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


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.


Looks like they do have Watchtower for business https://support.1password.com/reports/#create-a-business-wat...


To clarify, this is only for Vaults, so all passwords outside of Vaults have no visibility.


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.


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

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


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.


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.


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


While not necessarily specific to password management (and probably shouldn’t be for password management), it can be super helpful to self host an internal “flashpaper” service where devs/people sharing sensitive info can send each other one time viewable links. Creates an easy default way to securely share secrets and feels surprisingly fun to do!


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


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.


We use Bitwarden.

Every employee has a collection. When employee needs access to something, we add that password to their collection.

When they leave the company, we revoke access to Bitwarden and then change all passwords in their collection.

For small companies of maybe up to 100 employees, this is a super cheap and practical solution.


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


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


Use a password manager, like Bitwarden


(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)!


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


I'd avoid LastPass. The UI is awful, and they've been breached before: https://krebsonsecurity.com/2023/09/experts-fear-crooks-are-...


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


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."


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.


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

Use Okta for SSO.


Ditto this. We use this in our ~100 company and it works great. Plus, it can hold more than just IT/Tech passwords. Everyone in the company uses it constantly and only has access to what they need.


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


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


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


1Password or similar service w/SSO


I would suggest you to use a self hosted open source password manager like Passbolt.


Just rawdog it on the whiteboard


Zoho Vault


we tested this, it had many more admin controls and finer controls at the basic level that 1password


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.


> Easy ability to recover if an employee forgets their master PW

So the server can read all data or how does this work?


> * 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.


1password.com works well.


We use Azure Key Vault


Google SSO + KeePass file synced via Google Drive


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.


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?


Use something like 1Password and integrate with your SAML/SSO provider (Okta).

You have the ability to share a password to anyone even without an account (similar to OTS). Team vaults. Recovery. Etc..

Been using it the last few companies and it’s worth the money.

You always want to take into account who will manage this when it breaks and how often? Roll your own BW instance you’ll be in charge of it 24/7. Outsource the infrastructure to 1Pass and you really only have to manage policies and access.


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.


1Password for Business


Hashicorp Vault.


write it on a page an pass on


enpass.io


write it on a page and pass on /s


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?


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.


I think stack exchange would delete the question because it is too vague and open to opinion.


And (except on a specific site within their network), product recommendations are OT.


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!


Yes I realized later that OT might have two meanings, and the most probable one is not the same everywhere... but too late to edit.


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


there is no way to word this question to be appropriate for stack exchange. it fundamentally does not belong on stack exchange


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.


Decent chance that the asker and many of the good answers here are the professionals staffing security departments. This place is better than StackExchange for this kind of discussion. If you’re curious about how companies manage passwords, there are people with experience sharing. Why not sit back and learn?


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


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


Asking on Hacker News IS consulting with IT professionals.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: