I'm unusually strict about maintaining a separation between work and personal (for instance, I would never allow my personal smartphone to connect to my employer's WiFi), so I wouldn't use personal keys on a work machine at all.
But if those keys (or passwords, etc.) are generated for work purposes, I consider them to be as much company property as the machine itself, so I'm no more protective of them than I am of any other sensitive company data.
How do you feel about giving your colleague your password?
My personal opinion is that I can hold someone legally culpable if their account does something like leak financial information; you have a professional responsibility to secure your account from absolutely everyone.
Administrators acting on your account must of course be heavily logged and audited, which is the case.
> How do you feel about giving your colleague your password?
I usually don't, mostly just out of good security habits, but also because most employers specifically prohibit doing that.
Almost always, your colleague can be given his own access to whatever the password is for anyway. If that's not possible, then I'll share the password and change it immediately after my colleague doesn't need access anymore.
> you have a professional responsibility to secure your account from absolutely everyone.
I agree -- that's part of treating credentials the same way as all other sensitive company data. But it's still my employer's data, not mine.
If I quit the company or if my supervisor wants to see the contents of my machine, I'm fine with that. The machine and everything on it belongs to the company anyway.
Ok, but your private key, session tokens and CLI access tokens (kube configs, gcloud etc;) are your password in those situations.
They tie to your identity, thus you must not treat them the same as company secrets, they are professional personal secrets which should not be disclosed or allowed to fall into anyone elses hands (less they be revoked and cycled).
It's not just good security posture it could affect your career quite badly or lead to legal issues.
> I agree. I don't think I've said anything counter to that (or perhaps I wasn't being clear?)
I think given the context of the thread (don't touch my secrets), saying that you don't have anything you would consider confidential towards your employer or colleagues is a direct contradiction to what I stated.
That's why I'm "arguing" because my employer/colleagues should not have access to my private key, ever.
There are several very legitimate times when my employer needs to have access to my keys. If I'm leaving the company, for an obvious instance.
But my core point is that such keys/passwords aren't really mine, they're the company's and in the end, the company gets to decide what I'm to do with them.
I think the building access keycard is a perfect analogy. I'd never let anyone borrow mine on my own volition, but if the company wants to retrieve it from me, that's their prerogative. It's theirs, after all.
If an employer needs someone’s particular keys something probably went wrong or there’s bad processes in place. But that aside I think the default course of action should be to aggressively guard your secrets and tokens since they represent you. Not as personal or private property but to keep someone (be it a fellow employee or a 3rd party attacker) from impersonating you without authorization.
There are exceptions but the circumstances where an employer would need to retrieve my keys without my assistance are extremely rare and in those instances it’s unlikely I’d still be an employee anyway.
The handing of the keycard is necessary to ensure it's destroyed and can't be used as a "proof" you work somewhere (most access cards these days have your name, face and the company logo printed on the front).
The keycard will be removed from the access list to the building even when it's destroyed, they're not considered reusable by most companies.
Your private key is not reusable, it should be destroyed and revoked from all system when you leave a company.
We could destroy the keycard with both parties present, that seems safest. I don't mind turning in a private key permanently and getting a receipt at the time, but it needs to be very clear that it's no longer my responsibility.
> but to keep someone (be it a fellow employee or a 3rd party attacker) from impersonating you without authorization.
Aside from a third party attacker (which is well-covered by my normal practices), that's a threat model that I'm personally not worried about at all, really. In part because I've never seen or heard of that happening and in part because if it did, I am confident that there are enough records to be able to prove it.
Internal abuse and attacks aren’t as rare as they should be. You’d be amazed what someone will do to risk their job or even career on impulse or poorly considered risks.
Isn't this largely the point of company directory services? The machines/routers/applications/etc are all doing their authentication against the directory service, and permissions are granted and revoked there. Its a large part of running a company with more than a couple employees because when someone leaves you don't need to run around changing passwords and wondering if they still have access to the AWS account to spin stuff up, or punch through the VPN. The account in the directory service is just deactivated and with it all access.
By default this should be what is happening on all but the most ephemeral of machines/testing platforms/etc. And even then if its a formal testing system it should probably be integrated too.
Directory service integration BTW is the one feature that clearly delineates enterprise products from the rest.
> If I quit the company or if my supervisor wants to see the contents of my machine, I'm fine with that. The machine and everything on it belongs to the company anyway.
I'm fine with that, but I still will not share my passwords. I'd be happy to reset the passwords for them if they can't access the data by other means, but as another commenter pointed out, the fact that anything needs to be recovered from my^H^H not my laptop indicates mistakes were made.
But if those keys (or passwords, etc.) are generated for work purposes, I consider them to be as much company property as the machine itself, so I'm no more protective of them than I am of any other sensitive company data.