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
