Inline..
-----Original Message-----
From: Derick Anderson [mailto:danderson@vikus.com]
Sent: Thursday, September 01, 2005 2:32 PM
To: focus-ms@securityfocus.com
Subject: RE: Group Policy: multiple password policies in the
same domain?
Why two policies?
I have single domain that contains both end users and
mission-critical service accounts, and our company must be
SAS70 type-II certified. So the auditors come and say, "You
must have secure password policies."
This amounts to (in our case) at least 8 character passwords,
a maximum age of 90 days, complexity requirements, a lockout
policy of 5 attempts with infinite lockout, and a 1 day
period between failed attempt count resets. When I first came
the minimum length was 7 characters. The day I upped it to 8
you should have heard all the crying.
[Brady]
Let them cry. They'll get used to it. We had the same
issue, but stick to your guns and they'll stop complaining.
People only complain when they learn it will get them what
they want. Plus if you are required to have 8 character
passwords, what can you do about it? It must be that way.
[End Brady]
The best thing about the SAS70 audit is getting to blame someone else
for doing things right. =) I've had similar issues with developers who
thought they needed full control in the production database. It's always
handy to say, "If we don't we won't pass our audit" when the idea of
role separation doesn't quite get through to them. Also the CIO backs me
up 95% of the time...
My concern is that they'll start writing the passwords down. I've tried
educating them about passphrases (which I use to create 20+ character
passwords for critical accounts) but only a few of them have been able
to make the switch. There seems to be some mental block about how long
the password is, even though passphrases are easier to remember because
of memory chunking.
I consider 8 characters the bare minimum for a secure account
password.
Unfortunately our users cannot fathom security and while I
personally use passphrases that exceed 20 characters I doubt
very much that I could ever get the whole company past 10 and
then I'd spend all my mornings unlocking accounts or
resetting forgotten passwords.
The second issue is the lockout policy and password age - if
you are only going to require 8 characters you'd better have
some sort of lockout policy, in my opinion. However, when a
mission-critical system runs as a domain service account, and
a developer tries to use that same account for "debugging"
(.NET machine config for the uninitiated) and uses the wrong
password, it locks out the service account and DoSes the
system. Clearly a security risk from an availability standpoint.
[Brady]
Why would a developer have access to mission-critical domain
service account? If he needs access, give him a separate
account with the same permissions if necessary.
[End Brady]
The developer didn't have access to the account, but did have access to
try and use it (because we've got one domain). 5 tries later our
production system went down. In fact, the developer didn't even need to
use that account, just thought that he did.
So the dilemma is that I need shorter passwords with tighter lockout
policies for users, and longer passwords with no lockout policies for
service accounts, and I have to be able to demonstrate that
the password
policy is in effect to the auditors. I can make the service account
passwords as long as I want, but unless it can be proven that this is
the case, we don't pass the audit next time around.
[Brady]
You don't need shorter passwords. You need to tell your users the
company is required to have at least 8 character passwords,
and if they
don't like, tough, there is nothing you can do about it. And you need
to not let anyone use your service accounts.
[End Brady]
When I said "shorter" I meant 8 characters plus. For me, a normal-sized
password is at least 12 completely random characters or 20+ for a
passphrase. Again, with the service accounts, no one can use them but
the password policy allows them to be locked out if people try. I want
the lockout policy for our users, just not the service accounts.
Derick
---------------------------------------------------------------------------
---------------------------------------------------------------------------
