Hacker News Reader

Comment by tossaway9000 | Hacker News Reader

It's not a "private" key if its shared. Only the end user needs to know the private key details.

Consider the usecase of generating a user their initial password for a service, this almost always results in the user needing to immediately reset their password after initial login, this doesn't happen if someone is generating both parts of the key pair for you.

My sysadmin doesn't need to know my password, and doesn't need to know my private key or passphrase, that would allow them to impersonate me.

View on HN

well, your sysadmin created your AD account, and probably has some means of root access to your box too, so they could already impersonate you. *

*this may or may not be true depending on how Enterprise-y your workplace is.

If nothing else, they need to be able to access your files in case you leave.

Unless it's all encrypted with the user's own password: sure, you can always invoke the admin powers and override the password field in the database or whatever. But the default mode should be that an account is only accessed by the person it belongs to.

Even as a security firm we have some exceptions in our company (disk encryption password for a physical device in the office is in a shared vault, for example), or support might do a remote control session with the user present, but it's definitely not the default setup procedure for a new employee to have shared credentials for example.

I think it should be noted that even with with encrypted data you'll generally just encrypt the master key with multiple passphrases; one (or more) master keys for admin use and one for the user themselves. There's really very rarely a good reason to share any secrets.

It's pretty much a necessity for any larger business that device data be protected with the user's own password and with a master password known to IT so that it can be accessed when the user's password is inevitably lost.

The difference is in the kind of audit trail it leaves. If a sysadmin impersonates a user, that leaves a different kind of trail than a user logging in with their own key that only they can access.

In principle, the sysadmin should explicitly avoid knowing any of the user's secrets, because if they do, the user can shift blame onto them: "It wasn't me, it was the admin!".

I will never generate a private key for a user and will initiate a reset process for any passwords and other personal secrets revealed to me; to do anything else would be irresponsible.

Reply on news.ycombinator.com