Password Security?
-
@Carnival-Boy said:
Who down voted my post? I'm only kicking round a few ideas here, saying what I do, and trying to pick up a few tips on how I can improve. I'm not out to piss anyone off. There's no need for down voting, surely?
Wasn't me. Does the activity feed tell you? I see when people upvote. Never paid attention but I bet downvotes are there too.
-
@Carnival-Boy said:
@scottalanmiller said:
Am I? In what way? They know that you have the user's password. They want you to act as the user. What does this have to do with the domain admin?
Best example I can think of - I'll give my banking details to my bank manager, but I wouldn't give them to my neighbor. I trust my bank manager with my bank details because that's kind of his job - to protect my money.
I'd also expect my boss to keep a close eye on me, as the keeper of data, for good governance. I don't expect him to have the same level of oversight with users, because they should have less access. The company knows I have access to all company data, and they mitigate the risks accordingly.
Okay, I'll agree with that. Not sure about the bank manager bit, but the boss and oversight bit. A bank manager has strict monitoring and regulations that oversee him because they don't really trust him either. But that you are viewed as a risk and monitored extra because of that makes some sense.
-
@Carnival-Boy said:
What I do know of the law (mainly learnt through reading John Grisham and watching Law & Order) is that a defence has to be not only technically possible but credible. It's possible, for example, that the IT Manager logged on to your PC and downloaded loads of porn, but is it credible?
Very credible if the business wanted someone fired and needed a reason. Is it credible to think that someone would do that at work? They do, but it's pretty crazy.
If the goal is to commit a crime (steal money, defame a third party, etc.) using someone, anyone, else's identity can be very useful. It depends on the end action, surely. But in the US, at least, the difference between an account being an "identity" account and it being a "shared" account is pretty big. In this case, that's not "his" account but it is an account that he shared equally with you.
-
@scottalanmiller said:
In this case, that's not "his" account but it is an account that he shared equally with you.
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".
Every time any support guy makes a desktop sharing session to do some work he is technically logged in as that user.
-
@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.
