Re: password policy with regard to application userid

[krymson () gmail com]

Here are some points.

0) You need to ask who all needs access to this account? Or is this buried in a config file (like the machine or 
web.configs) that only really needs to be set once and otherwise the password is known/accessible just to your and your 
team? Find out the scope. If too many people have it and the account has huge access...you want to rotate it regularly. 
Also, make sure you know if this account/application is subject to more stringent requirements for PCI or other 
regulations...that may just outright dictate your policy.

I will assume this is just a buried service password that no one really needs to know and is otherwise set once and can 
be forgotten (potentially) for an application that is not otherwise governed by extenuating regulations.

1) If nothing else, document the existence of the access somewhere. That way in 2 years when something changes and 
breaks this, you know what was there, blah blah blah.

2) Give it a 16+ character alphanumeric/symbols password. You don't need to remember this if it is a service account, 
so complex is not an issue. Go as complex as you can.

3) You don't necessarily NEED to change all service accounts every 60 days or so, but it is nice to shoot for every 6 
months or year or something. I think most shops tend to set this very complex, protect who sees the account, and then 
rarely (if ever) changes them. It can be a real pain in the ass and really affect application availability if you 
change passwords every 60 days. Keep the pain of changes in mind.

4) Make sure the account only has privileges to do what it needs to do and connect what it needs to connect to, and 
nothing else. This way if it does become disclosed or someone can see the password, the account is very limited in use. 
This probably means not making it a Domain User and instead really stripping it down. This is an art and can be very 
painful for shops whose developers are not used to this.

That framework should get you started, plus anything else others can add.



<- snip ->
What would be a reasonable password policy with regard to userids used in applications?

For example Business Objects needs a system level userid to intergrate with active directory. What would the security 
implications be if this userid's password wasn't changed?

Standard users follow a policy in which they have to change their password every two months.

Thanks