Password Security?
-
In a smaller environment, there can be lots of reasons why logging in as users would be desired, if not desirable. There is little other way to really test setup, for example. If you have power users, you probably never need this. Internally at NTG, for example, you never need to log in as someone else, ever. Because we can move icons around for ourselves and do other basic tasks. We know how to screen share when that is needed.
Non-technical end users very often need a degree of hand holding that actually results in doing things on their behalf. While that can be automated and done in a way that does not require a password, it is extremely hard. The smaller the environment, the more of a pain it is to work around. The issue that @Carnival-Boy is facing is real, the need to log in as them very commonly does exist. It's not good, but it is real and sadly there is no good way around this on Windows.
If this was Linux, the solution is simple. This is really a combination of Windows limitations combined with user deficiencies.
-
@Dashrender said:
Are there reasons you would need to be on a user's computer where they wouldn't be aware of it? And if so, do you really need to log in as them? If so, that sounds shifty to me.
Could be for shifty reasons, of course, but what we see is a huge desire to have people (IT) fixing end user machines or software when the end user is busy elsewhere. The last thing that you want to be doing is basic work while they are waiting, tied up or looking over your shoulder.
-
@Carnival-Boy said:
I have 3 Domain Admin accounts. One is for my use. One is used by our MSP (which they write down, I don't know where they write it down exactly), and one is for emergency use (eg I get run over by a bus). The emergency one is stored in Keepass. Two other people have access to the Keepass database, and the Keepass password is written down (yes, it is written down!) and stored in the safe.
Ah ha, I think that this is a better description than you first gave. Having your KeePass as the emergency holder of the domain admin account is better. I would think about improving that with a critical password used only for central "hit by a bus" passwords and keeping everything used regularly in a different database. Keepass does that easily.
-
@scottalanmiller said:
Could be for shifty reasons, of course
I'm not shifty, honest
I always have a backlog of minor helpdesk tickets that are often user profile related. Partly to offer the least inconvenience to users and partly because I'm a sucker, I mostly do these kinds of tickets after hours when everyone has gone home. Whilst most of my colleagues are at home watching the telly and sipping a beer, I'm often still at work, alone, fixing their minor bugbears.
The other advantage is that if the user isn't around, I'm not under any time pressure to complete the job. So I might be working on several jobs at once.
I also don't normally know exactly when I'll work on the ticket, so I can't let users know in advance, it depends on my workload, and whether I can bothered to stay late. An unexpected bit of warm weather and bright sunshine will normally see me finish early and head to a beer garden, leaving my helpdesk schedule in tatters.
-
I appreciate that a lot of my workflow is done out of convenience (either personal or user) rather than necessity. I don't have to work out of hours. I don't have to go to the pub instead of working.
But I'm still waiting to hear the actual risks of my workflow. Where's the harm? Only when I fully understand that can I balance risk against convenience.
-
@Carnival-Boy said:
@scottalanmiller said:
Could be for shifty reasons, of course
I'm not shifty, honest
I always have a backlog of minor helpdesk tickets that are often user profile related. Partly to offer the least inconvenience to users and partly because I'm a sucker, I mostly do these kinds of tickets after hours when everyone has gone home. Whilst most of my colleagues are at home watching the telly and sipping a beer, I'm often still at work, alone, fixing their minor bugbears.
The other advantage is that if the user isn't around, I'm not under any time pressure to complete the job. So I might be working on several jobs at once.
I also don't normally know exactly when I'll work on the ticket, so I can't let users know in advance, it depends on my workload, and whether I can bothered to stay late. An unexpected bit of warm weather and bright sunshine will normally see me finish early and head to a beer garden, leaving my helpdesk schedule in tatters.
This is what gets us. It's often best to work on user machines during the night when they are not around. Way more productive for IT and for the end users.
-
Since you've already dismissed being sued by an employee for using their credentials, I guess the only other real harm is the potential, as @scottalanmiller said, people tend to use the same passwords all over the net.
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.
-
@Dashrender said:
Since you've already dismissed being sued by an employee for using their credentials, I guess the only other real harm is the potential, as @scottalanmiller said, people tend to use the same passwords all over the net.
It's far less being sued by the end users as being unable to prosecute them in case they do anything. They can point to the fact that their passwords were never their own and no action taken in their name was using their identity. It's a fundamental difference in how businesses typically operate but lots of SMBs choose the "anonymous" user route. Big companies typically have strong security and the end user's identity is their own. But it is not that uncommon for small shops to make the identify be one of ambiguity. It's not that they will sue you, but that you cannot sue them.
-
@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.
I might be tempted to do it in a shop that is too small for AD. It really is tempting to do. I understand the desire to do it. But only with really good policies and communications with people and only if the company generates the passwords. Once you have AD, though, I would not want to do it.
Moving to something like Chromebooks you would be even less likely to do it.
-
I've provided evidence of user misuse of company systems during disciplinary proceedings but in all cases the user admitted guilt when presented with the evidence. I'm not sure what would happen if they claimed that I could have used their credentials to frame them. I'm not sure that would stand up as a valid defence in a court of law. I just don't think the "but the IT guy could've done it" sounds like a strong defence. But I'm no lawyer. I'd be interested to hear some real life examples.
We do have a problem here with users giving other users their passwords. It's against company policy, but I know it goes on. I try not to get too involved as it's primarily an HR issue, not an IT issue. Mainly I try and point out to users what might happen if someone used their credentials to commit something illegal, in the hope that I can scare them into better behavior. But no-one seems to care apart from me.
I'm always amazed when users come up to me and say things like "Bob is on holiday, can you log on to his machine for me so I can check if he had an e-mail from X last week". Er...no.
-
@Carnival-Boy said:
I've provided evidence of user misuse of company systems during disciplinary proceedings but in all cases the user admitted guilt when presented with the evidence. I'm not sure what would happen if they claimed that I could have used their credentials to frame them. I'm not sure that would stand up as a valid defence in a court of law. I just don't think the "but the IT guy could've done it" sounds like a strong defence. But I'm no lawyer. I'd be interested to hear some real life examples.
Manipulating the logs would be "but the IT guy could have done it." Requiring that you have full identity ownership on par with their ownership of it means that you are an equally culpable party. That's a bit different. Any evidence against them based on their account would be equally against you. You are not an "outside chance", but every bit as much of a primary holder of the identity.
I would say that it is more than a strong defense. It completely eliminates any reason to assume that it was the person whose name was assigned to the account. It is the difference between the account being just a name and it being an identity.
If you have other evidence or users who are idiots or who just want to get caught, then you are fine. But if you are counting on an identity system that is not at all an identity system, then there is really nothing.
Where is the line between this and creating accounts for people who don't even work there or who are never told their passwords? You could do unlimited actions on their behalf. I'd say that the opposite is true - claiming that assigning a username that looks like a human name is a weak defense compared to who owns and controls the account and its password.
-
@Carnival-Boy said:
We do have a problem here with users giving other users their passwords. It's against company policy, but I know it goes on. I try not to get too involved as it's primarily an HR issue, not an IT issue. Mainly I try and point out to users what might happen if someone used their credentials to commit something illegal, in the hope that I can scare them into better behavior. But no-one seems to care apart from me.
That's a problem too, but I find it surprising that you point out the legal issues of it when they hand it out and not when you require it to be shared. This is the pot calling the kettle black. You are admitting to them that there is a security problem and telling them not to do it while you are doing it to them already. No wonder they don't take heed. Your actions are speaking louder than your words. I agree that it is an HR issue, but I think employees would wise up and point out that any HR policy against such a thing violates IT's policy and that management needs to sort out its confusion before making staff do one thing or another.
You try to scare them yet when we pointed out the risk in this thread, you dismissed it. Why do you dismiss it with you sharing their passwords and not with them sharing with each other?
-
@Carnival-Boy said:
I'm always amazed when users come up to me and say things like "Bob is on holiday, can you log on to his machine for me so I can check if he had an e-mail from X last week". Er...no.
It's only so surprising since they know that you have his password and can do that. It's not surprising that you won't do it, but for them to assume that that is a primary reason for why you keep his password is not really much of a stretch.
-
@scottalanmiller said:
@Carnival-Boy said:
I'm always amazed when users come up to me and say things like "Bob is on holiday, can you log on to his machine for me so I can check if he had an e-mail from X last week". Er...no.
It's only so surprising since they know that you have his password and can do that. It's not surprising that you won't do it, but for them to assume that that is a primary reason for why you keep his password is not really much of a stretch.
Also, while this is outside the scope of this conversation, why didn't Bob setup someone to have access to those emails, or put rules in place, etc to allow things to be taken care of during his absence? (short of unexpected illness)
-
@scottalanmiller said:
It's only so surprising since they know that you have his password and can do that. It's not surprising that you won't do it, but for them to assume that that is a primary reason for why you keep his password is not really much of a stretch.
You're confusing users with domain administrators. I have access to all company data because I'm the IT manager. Users don't because they're users. There's a very clear distinction. You're treating them the same.
-
@Dashrender said:
Also, while this is outside the scope of this conversation, why didn't Bob setup someone to have access to those emails, or put rules in place, etc to allow things to be taken care of during his absence? (short of unexpected illness)
This is what annoys me. I go to a lot of effort to make sure everything is covered when I go on holiday, yet other managers do nothing when they go away (out of laziness in all probability). Yet when the shit hits the fan, I'm expected to sort everything out. I have to organise my own holidays and everybody elses.
Sorry, rant over.
-
@Carnival-Boy said:
@scottalanmiller said:
It's only so surprising since they know that you have his password and can do that. It's not surprising that you won't do it, but for them to assume that that is a primary reason for why you keep his password is not really much of a stretch.
You're confusing users with domain administrators. I have access to all company data because I'm the IT manager. Users don't because they're users. There's a very clear distinction. You're treating them the same.
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?
-
@Carnival-Boy said:
@Dashrender said:
Also, while this is outside the scope of this conversation, why didn't Bob setup someone to have access to those emails, or put rules in place, etc to allow things to be taken care of during his absence? (short of unexpected illness)
This is what annoys me. I go to a lot of effort to make sure everything is covered when I go on holiday, yet other managers do nothing when they go away (out of laziness in all probability). Yet when the shit hits the fan, I'm expected to sort everything out. I have to organise my own holidays and everybody elses.
Sorry, rant over.
Yeah, not exactly fair. HR should keep that on a more even keel. But, bottom line, you are probably more critical than normal staff.
-
@scottalanmiller said:
You try to scare them yet when we pointed out the risk in this thread, you dismissed it. Why do you dismiss it with you sharing their passwords and not with them sharing with each other?
I'm not dismissing anything. I started this thread saying I'm seeking to be proven wrong. I'm skeptical of the legal risks and since none of us are legal experts or have any real world examples, I remain skeptical.
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?
Answer me this, why is the defence "the IT Manager knows my password because I told him it therefore he could have done it" acceptable, but "the IT Manager knows my password because he used a brute force attack to find out what it is" not acceptable? Both are technically possible. I've seen penetration tests where user passwords are discovered in like 5 minutes.
-
@scottalanmiller said:
@Carnival-Boy said:
@scottalanmiller said:
Why is the domain admin password written down? Is this a break-glass system for turning over admin access to a third party?
Essentially, yes. I've read tons of stories of networks getting compromised, usually as part of a penetration test. I haven't actually done a pen test here, but I've no doubt that our network could get compromised. What I haven't heard though, is networks getting compromised via a Keepass database (or similar password management tool). Those products seem pretty robust. That doesn't appear to be the weak link in our security.
Keepass is pretty secure. But how it is used is what matters. Are you the only one with access to it? If so, isn't that a point of fragility? If not, that's a lot of password exposure. Are you confident that no one is writing down the Keepass password?
Keepass is great, I just wouldn't keep the one master domain password there.
I keep a few passwords in the one I maintain. The break-glass plan as you put it earlier for me is a sealed envelope in a fireproof save that I check regularly. Even has a break seal attached so I know if it's been used without my knowledge.
