Password Security?
-
@scottalanmiller said:
Wasn't me. Does the activity feed tell you? I see when people upvote. Never paid attention but I bet downvotes are there too.
No. It doesn't tell you. I can't be doing with this - I'm always very open and honest on forums but I'm just too sensitive
I'll end up leaving the community, a pale shadow of my former self, my self-esteem shredded. -
I'll just throw it out there - I wasn't the one who down voted it either. I'm surprised the system tells you who upvoted but not downvoted - are we going for the ebay way of positive only remarks.
Carnival Boy - We've given you the reasons why we think you shouldn't share passwords, even with IT personal (even worse, IT shouldn't write them down). Can you flip this on it's ear and show us how it's not a security risk by sharing?
The main thing I've picked up from pro password lists people is simplicity for themselves - but I ask, is that that job of IT? They don't want to have to deal with users calling to reset passwords, IT wants to work after hours, etc.While I can understand we want to keep employees as productive as possible, rarely are they not responsible for whatever you're fixing on their machines. Having them around to answer questions and to learn what it takes to fix the problems they make should be beneficial to all, no?
-
@Carnival-Boy said:
@scottalanmiller said:
Absolutely not the same thing at all. But if you're going down that route then your statement applies to every time the IT guy logs in as the user. Resetting the password makes no difference, you're still logging in as that user. The "IT guy did it" defence simply becomes "the IT guy must have reset my password, logged in as me, done the deed, then reset my password".
No, it remains different, because it alerts the end user that their account has been reset. They can go to security and inform them that their account has been compromised. There is a security mechanism in one case to alert the end user, the other hides it from there. Even with the ability to reset and seize, there is a big difference between seizing an account and sharing it.
-
@Dashrender said:
I'll just throw it out there - I wasn't the one who down voted it either. I'm surprised the system tells you who upvoted but not downvoted - are we going for the ebay way of positive only remarks.
Carnival Boy - We've given you the reasons why we think you shouldn't share passwords, even with IT personal (even worse, IT shouldn't write them down). Can you flip this on it's ear and show us how it's not a security risk by sharing?
The main thing I've picked up from pro password lists people is simplicity for themselves - but I ask, is that that job of IT? They don't want to have to deal with users calling to reset passwords, IT wants to work after hours, etc.While I can understand we want to keep employees as productive as possible, rarely are they not responsible for whatever you're fixing on their machines. Having them around to answer questions and to learn what it takes to fix the problems they make should be beneficial to all, no?
I'll side with CB on this point. I see huge value in the "sharing" method. I won't do it, but I see the value. I think that the risks to me personally outweigh any benefit to the organization. But I understand that it makes life so much easier for both IT and for the end users - until something goes wrong.
-
@scottalanmiller said:
No, it remains different, because it alerts the end user that their account has been reset. They can go to security and inform them that their account has been compromised. There is a security mechanism in one case to alert the end user, the other hides it from there. Even with the ability to reset and seize, there is a big difference between seizing an account and sharing it.
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.
-
@Dashrender said:
Can you flip this on it's ear and show us how it's not a security risk by sharing?
It is a security risk. The issue is whether the risk outweighs the benefit.
-
@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?
