Many companies run around with non-expiring service IDs not realizing how insanely insecure that is.
Look around people, MS was even hacked because of unchanged service IDs several years back and I recall hearing how billg had put out a message that they were going to stop using non-expiring accounts. I expect that dropped by the wayside because we haven’t seen many new ways of handling services[1].
Think about all of this logically…. You force password changes so that a password can not be the same thing for long enough to hack it through various brute force methods or because it has been the same too long and you don’t know who all has the password. So then you take IDs that are more likely targets for hacking than normal IDs due to
1. Having more power/rights than normal IDs
2. Being known by multiple people so there is always question as to who did what
and then you make them non-expiring and let them stay unchanged for a year or more….. My comment on this… Service IDs or any IDs known by multiple people should have their passwords changed far more often than regular passwords. That is, if you truly are looking for security.
What brain dead security people are making those decisions? They just made a mockery of all their other decision making processes for setting a password change policy in the first place. They have said password changing is not necessary for their corporate security. If anything, service IDs should be changed more frequently than normal user IDs.
The number one argument I hear about having non-expiring IDs is that the password needs to be changed in a controlled fashion, it can’t just be allowed to expire…
My response to that is always… Fine, change it in a controlled fashion, you know exactly when it is going to expire, make sure you change it before then. This gets fought and it goes to policy/security people who say, “Ok, we will grant a non-expiring password but you have to change it every X days!!!” and have no documented mechanism to check back up on these people and IDs.
How many people grant non-expiring IDs to application owners who say they will change their password at least every X days? Raise your hand.
How many actually go back and audit those same IDs and shut them down if the password is older than that X days? Raise your hands.
I expect the first number of hands far exceeds the second number and it is probably one or two people who tend to get berated for annoying their “customers” who did raise their hand. Who wants to take responsibility for knocking down a running application? IT doesn’t make money, the business does… Security is the kind of thing that IT people get fired over yet they have so little voice in it when it really comes down to it because very few companies are in the business to make computers or be secure. They make cars, or they make planes, or they sell this or that. All things that security can slow down.
This is the kind of thing I get fired for because I will take that responsibility, I think it is more important that companies be secure because I know the minute they are compromised they are going to chew me out asking who did it and how assuming the company wasn’t wiped out due to the security breach.
I have seriously had managers ask “Who logged onto a specific ID.”
My response… “Well whomever has the password of course!”
“No, specifically who logged on and did this.”
My response… “I don’t know, the mechanism I have for tracking the WHO is completely compromised by how you use the system with that ID. For a small fee, we can install a web cam on every machine in the world that people can log into and we can work out a mechanism around that if you would like to track it the next time your application gets hacked…..”
You have people that want to use non-expiring IDs… try these alternates…
1. Service passwords must be changed monthly. Not many people have a password policy less than 30 days.
2. Allow the ID to “set” its own password. That’s right, in AD domains you can say who can “SET” a password. Make it so the service ID can set its own password itself, then it doesn’t have to recall the old password to change it. You set the new password on the account, you set it on the service, the service restarts. Of course that last part is the tricky part to do. MS needs to work on that it should not be that tricky. Users logged in can change their password and not logoff (even though it is recommended).
3. Every Service that has to run in in the context of an ID uses its own ID. Even if it is the same service on multiple machines. This helps lots of things with a few of them being A) Makes it so you can change the password B) Reduces the question of what is using this ID? C) If the ID gets locked out the impact is reduced.
4. Just tell the people no. Say we think from a security standpoint that is an absolutely assinine thing to do and you want it simply because you are lazy and don’t want to come up with a design that can account for having to change the password and I am not here to allow your laziness to compromise our company’s security.
joe
[1] LocalService and NetworkService are a step in the right direction. But we need more, much more.
