Password Security?
-
@Carnival-Boy said:
I'm afraid I'm just not getting the difference. In one case, I login as the user with password X, in the other case I login as the user with password Y. What's the difference? In both cases I am logging in as the user. Your argument would only make sense to me if you said I should never login as a user. It seems to me that as soon as I login as that user, his account is compromised, and my ability to discipline him based on his user ID is invalidated.
Anyone can break into your house and make prank calls from your phone. There is a huge difference between someone breaking in and there being broken glass so that you know that someone broke it versus sharing a party line and having no way for the user to know that their account is "compromised."
As an end user (I don't do desktop support) what you are talking about is a major difference to me. In both cases you can masquerade as me, that is an unavoidable case. But in one case it is continuous and transparent - you and I always are peers under my credentials. In the other, I own my account and if you mess with it I know immediately and can report that my identity is compromised since the last time that I logged in and until now and I can reset the password and monitor for it to happen again.
Yes, you can hijack my account during that window. But there is zero denying that you, not I, had access to the account during that time. It literally switches the owner from me to you until we reset it again. At no time is it ever shared and the time when you are involved is know.
-
@Carnival-Boy said:
It seems to me that as soon as I login as that user, his account is compromised, and my ability to discipline him based on his user ID is invalidated.
Yes, as soon as you can log in that is. With a shared password, his account is never his account. It is always yours too. He never owns or controls it. He never knows how many people you have shared the password with. Nor you him.
With a reset, he knows that you don't know his password. Once you take over, you know that he doesn't know his password. The system is only compromised after seizure of the account takes place.
-
@scottalanmiller said:
With a shared password, his account is never his account. It is always yours too. He never owns or controls it. ...
I would say he never owns it under any scenario because as Domain Administrator I have the ability to login with his account (by resetting the password). It's that ability that prevents his ownership, not the fact that I don't know his password. The fact that I don't know his password becomes irrelevant once I have the power to simply reset it and then use his account.
But there is zero denying that you, not I, had access to the account during that time.
Out of interest, how would I prove that?
-
@Carnival-Boy said:
I would say he never owns it under any scenario because as Domain Administrator I have the ability to login with his account (by resetting the password). It's that ability that prevents his ownership, not the fact that I don't know his password. The fact that I don't know his password becomes irrelevant once I have the power to simply reset it and then use his account.
You can say that but that is not how a court interprets identity. Knowing or not knowing the password is key. No different than how your bank account is yours, not the banks. Your credentials are yours. If they change them, you will know.
Knowing the password really does make all of the difference. The ability to take something from someone is not the same as having taken something from someone. I can steal my neighbour's car, but that's not the same as having stolen it.
-
@Carnival-Boy said:
But there is zero denying that you, not I, had access to the account during that time.
Out of interest, how would I prove that?
Because you can log the password reset and know that he lost access. Those logs can be sent elsewhere to where you have no control of them. Auditing takes care of this. You can disable that to hide what you are doing, but you can definitely make it such that you cannot take over identity without someone knowing that it was done.
The user also knows, the next time they try to do anything, that their account was compromised because you cannot fake their password. So there are two audits to catch you.
-
@scottalanmiller said:
I can steal my neighbour's car, but that's not the same as having stolen it.
It's more like you can replace the locks on your neighbour's car, drive it around a bit, then leave a note on the windscreen telling him you've used his car and he needs to replace the locks again.
-
@Carnival-Boy said:
@scottalanmiller said:
I can steal my neighbour's car, but that's not the same as having stolen it.
It's more like you can replace the locks on your neighbour's car, drive it around a bit, then leave a note on the windscreen telling him you've used his car and he needs to replace the locks again.
Yes exactly. That's a great analogy. You have a "master key" that removes the old locks and makes it impossible to hide the fact from your neighbour that the locks were changed. So while you can borrow the car, you can't borrow the car and not have him know. So he can report that it was borrowed or record it or whatever. That way you can access it when you have to, but he isn't on the line for how you drive it while you have it.
Then when you are done, he resets his "key" and takes responsibility back for the account.
-
@scottalanmiller said:
So there are two audits to catch you.
Are we trying to catch me or to catch him? He doesn't have to give me his password, or he can always change it if he's concerned I have it.
-
@Carnival-Boy said:
Are we trying to catch me or to catch him? He doesn't have to give me his password, or he can always change it if he's concerned I have it.
All perspective. You want to catch him. He wants to catch you.
In one case, you share culpability. So you are caught "together." In the other you don't share culpability, so you catch whoever needs to be caught.
The ability to catch you is the ability to catch him.
-
@Dashrender said:
But for my own piece of mind, and the fact that logs are really difficult to fake (destroy - sure, fake - not so much) I wouldn't do it.
The only potentially serious cases I've been involved in have involved me providing Squid logs of internet activity. These are very easy to fake, they're just text files. They also only list by IP address so are based on the PC not the user, so really don't stand up to any kind of scrutiny. In all cases, the employee admitted guilt, so I was never challenged.
-
Anyway, thanks for all the food for thought (and no thanks for the down vote!). It's made me consider my policies and working practices, which is always a good thing. I'm so busy I don't always think things through in much detail and it's great to have someone challenge me.
If I understand it correctly, the principal objection is that my company wouldn't be covered correctly during an employment tribunal. To a degree this is an HR issue, so I need to make sure that my boss (who is head of HR), understands our current practices and has the opportunity to change them.
The solution (reset password and let the user know what it has been reset to) isn't without its challenges. More so if the user is out of town or starts work when I'm not around - we work 24/7 but the IT department is only officially open 8 to 5, so there is a significant amount of time when users have no IT support.
A lot of the tools and practices that you would use to fix or configure a computer without logging in as the user aren't available to an SMB because they're either too complicated to learn or too costly (Office Configuration Tool, for example, is only available under Volume Licence, which SMB's don't always have).
-
@Carnival-Boy said:
@Dashrender said:
But for my own piece of mind, and the fact that logs are really difficult to fake (destroy - sure, fake - not so much) I wouldn't do it.
The only potentially serious cases I've been involved in have involved me providing Squid logs of internet activity. These are very easy to fake, they're just text files. They also only list by IP address so are based on the PC not the user, so really don't stand up to any kind of scrutiny. In all cases, the employee admitted guilt, so I was never challenged.
That makes things easy. That you had real logs, though, and potentially multiple witnesses to the validity of the logs or multiple reasons that they were in trouble probably added up. I doubt that the logs were the sole evidence?
-
@Carnival-Boy said:
If I understand it correctly, the principal objection is that my company wouldn't be covered correctly during an employment tribunal. To a degree this is an HR issue, so I need to make sure that my boss (who is head of HR), understands our current practices and has the opportunity to change them.
I would agree with this assessment, this is an HR issue. Clearly shared credentials have a place. The question is does it have this broad of a place in your specific circumstance and is HR okay with the pro/con of the situation. Several pros, several cons.
The biggest thing, I think, is that you have to not think of the login as being an "identity" anymore and more a convenience.
-
@Carnival-Boy said:
The solution (reset password and let the user know what it has been reset to) isn't without its challenges. More so if the user is out of town or starts work when I'm not around - we work 24/7 but the IT department is only officially open 8 to 5, so there is a significant amount of time when users have no IT support.
Because it is only a temp password, what about texting them the password? Texts are completely insecure (and I do mean completely) but as a side band alert to a reset, are fine.
Or what about using a personal email account for that kind of alert?
-
Yeah, I've used SMS for this kind of thing before.
-
@Carnival-Boy said:
Yeah, I've used SMS for this kind of thing before.
There is also password reset software that can be used. But normally not free.
