Live data from Hacker News

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

news.ycombinator.com

231–240 of 297 posts

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

#231

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…

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 zip…

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

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

#232
post #30

> 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 acces…

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

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.

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

#233

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…

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 . Shout out to the few enlightened/kind SaaS peeps that don't do this (e.g. Windmill.dev) !

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

#234
post #232

Earlier quoted context omitted.

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

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 S…

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.

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

#235
post #13

- 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 l…

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?

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

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

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

#237
post #164

Earlier quoted context omitted.

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.

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

#238

Earlier quoted context omitted.

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

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?

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

#240
post #201

Earlier quoted context omitted.

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 admi…

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…

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.
Post reply on HN