4 ms·

> We used gopass at one of the earliest startups I worked for until we realized that all secrets needed to be manually rotated every time an employee left. No

> We used gopass at one of the earliest startups I worked for until we realized that all secrets needed to be manually rotated every time an employee left. No password manager that I’m aware of solves this or even claims to. When an employee leaves, you need to assume that they retain control of all passwords they previously had access to. They could have made a copy that’s beyond the control of your password manager (for example saved the password in the browser). What helps are reducing shared passwords, relying less on passwords in general (SSO, IAM, …) but for some cases you just have to bite the bullet and rotate the credentials.

gregoriol 5y ago
Could it work by using 2FA with a key, and the employee has to return the key when leaving the company? (in the sense that you wouldn't have to rotate the passwords then)
- SahAssar 5y ago
  Most services don't have a good way to restrict 2fa to certain keys which would be required for that. Also that would still mean rotating any tokens/m2m keys that have been issued. The "proper way" would be to try to minimize how many tokens/keys are readable by employees (they should probably be only read by deployment jobs etc.) and use SSO for interactive logins. When offboarding a user it should be enough to remove the user from the SSO provider and rotate any tokens/m2m keys that the employee actually had access to (as long as the employee did not get access to issue new tokens). Unfortunately a lot of services treat SSO as a "premium" feature and require "call us" enterprise plans for it.
- Xylakant 5y ago
  No. You have to assume that the employee copied the password to a place that you have no control over - for example a browser-based password manager attached to a private sync account, possibly enrolled a second token that you have no control over. You don’t even have to assume malice for that to happen. Using hardware based keys for accounts that require shared access is a pain, sometimes even effectively impossible (AWS allows a single U2F token on its root account, effectively making it impossible to grant 2 or more people access to it, if using a hardware token) And then, not all services provide 2fa, less with a physical key and for some, 2fa is comparatively easy to circumvent. But all of that holds true for every password management solution that manages long-term credentials (that is: including api tokens, access keys, certificates, …) The only thing that saves you is personalized accounts that you can deprovision - from a management perspective I love SCIM and SAML, even with all their technical flaws.

gregoriol 5y ago

Could it work by using 2FA with a key, and the employee has to return the key when leaving the company? (in the sense that you wouldn't have to rotate the passwords then)

SahAssar 5y ago
Most services don't have a good way to restrict 2fa to certain keys which would be required for that. Also that would still mean rotating any tokens/m2m keys that have been issued. The "proper way" would be to try to minimize how many tokens/keys are readable by employees (they should probably be only read by deployment jobs etc.) and use SSO for interactive logins. When offboarding a user it should be enough to remove the user from the SSO provider and rotate any tokens/m2m keys that the employee actually had access to (as long as the employee did not get access to issue new tokens). Unfortunately a lot of services treat SSO as a "premium" feature and require "call us" enterprise plans for it.
Xylakant 5y ago
No. You have to assume that the employee copied the password to a place that you have no control over - for example a browser-based password manager attached to a private sync account, possibly enrolled a second token that you have no control over. You don’t even have to assume malice for that to happen. Using hardware based keys for accounts that require shared access is a pain, sometimes even effectively impossible (AWS allows a single U2F token on its root account, effectively making it impossible to grant 2 or more people access to it, if using a hardware token) And then, not all services provide 2fa, less with a physical key and for some, 2fa is comparatively easy to circumvent. But all of that holds true for every password management solution that manages long-term credentials (that is: including api tokens, access keys, certificates, …) The only thing that saves you is personalized accounts that you can deprovision - from a management perspective I love SCIM and SAML, even with all their technical flaws.