Live data from Hacker News

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

news.ycombinator.com

141–150 of 297 posts

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

#142

Earlier quoted context omitted.

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.

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

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

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

#145

Earlier quoted context omitted.

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?

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

#146
post #139

Earlier quoted context omitted.

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

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

> 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

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

#147
post #73

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…

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.

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

#148

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

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

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

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

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

Post reply on HN