S
Steve Riley [MSFT]
{...reposting...I think I might have triggered a word filter on the
Microsoft servers, never saw it arrive there...}
Account lockout is a poor substitute for good passwords -- and is one of the
most expensive security features you can use. Let's think about this by
considering the threat. What threat does account lockout (attempt to)
mitigate? Password guessing. How can you make password guessing attacks
become useless for an attacker? Two ways: implement lockouts or use good
(meaning long) passwords.
Consider the first choice, account lockouts. The typical cost to an
organization to reset locked accounts is US$75 per help desk call. In a
medium or large organization, this can become a very high monthly
maintenance cost. In nearly all instances, the call results from users
locking themselves out, not users encountering locked out accounts because
some bad guy was trying to guess passwords. Account lockouts have one
more -- very bad -- problem: they *create* opportunities for bad guys to
conduct denial-of-service attacks against accounts or entire domains! Even
if you use a timed unlock of, say, 15 minutes, then the attacker can write
his script to churn through thousands of bogus logon attempts every 15
minutes 2 seconds. So, contrary to your claim, enabling this setting
actually can have significant impact on usability.
Account lockout is there for people who absolutely need it. But I can't
think of any instance where this is true. Instead, have a policy that
requires simple passwords at least 15 characters long. Forget about
complexity rules that force people to write down passwords. A simple
15-character passphrase (think short sentence) is easy to remember, quick to
type, and far stronger than any short complex password. A passphrase like
this will withstand any kind of automated password attack, including those
based on rainbow tables. And you can even use a method that helps you
remember unique phrases for each site, if you wish:
* web mail: "my dog and i got the mail"
* shopping: "my dog and i bought some stuff"
* office: "my dog and i went to work"
* photo site: "my dog and i admired some art"
This is why we disable account lockout by default. There are much better --
and much less expensive -- ways to mitigate the threat.
You're right, there's no built-in method to automatically disable unused
accounts. A variety of third-party products can provide you with this
functionality. I suspect some of them might be free, perhaps simple scripts
even. I tried searching on "automatically disable unused accounts" and saw a
few hits that looked promising. This particular function, however, rightly
belongs in the HR process. A number of customers I've spoken with have
automated the account creation/disablement/deletion process, incorporating
it into HR systems. When a new user is hired, the account is created when
the user departs, the account is disabled some time later, it's deleted.
The HR systems take care of this, not domain or enterprise administrators. I
wrote more about this subject here:
http://blogs.technet.com/steriley/archive/2007/05/31/when-you-say-goodbye-to-an-employee.aspx
Password expiration is an important setting for everyone. It mitigates two
threats: employees sharing passwords and bad guys discovering passwords.
Because we can eliminate the second threat using long simple passphrases as
I described above, then we have only one remaining threat: password sharing.
Your estimation of how prevalent this threat is in your environment will
guide you toward choosing an expiration time that works for you. 42 days is
a reasonable default our own corpnet uses 70 days. My experience with most
customers shows that password sharing isn't a problem. So for those who do
enforce long simple passphrases, I suggest that a reasonable default for
expiration is 120 days.
Windows begins notifying you 14 days before your password expires. You can
change this time period through group policy. I was in a similar situation
recently. Last month my domain password expired while I was in Australia for
TechEd there. I could continue to log on to my laptop with cached
credentials (so I'm not sure why you say your laptops become bricked?), but
couldn't use Outlook Web Access or RPC+HTTP of course. So I connected to a
Terminal Server computer we have on the Internet, logged on there, and
changed my password.
--
Steve Riley
steve.riley@microsoft.com
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com
>
>
> "Anteaus" <Anteaus@discussions.microsoft.com> wrote in message
> news:8303A854-B8AC-4AA9-9B4C-CA68C2374739@microsoft.com...
>> Not a solution, but I 've always thought Windows' default security
>> policies
>> were daft, what with having faddist password-change requirements, yet NO
>> protection against dictionary attack, and NO way of identifying or
>> closing
>> disused accounts.
>>
>> It stands to reason that any system which permits remote access MUST have
>> a
>> limit to the number of password-entry attempts in a given period,
>> otherwise a
>> correct guess is inevitable given enough time. Yet, while windows has
>> this
>> capability it's (inexplicably) turned off by default. Even though
>> turning it
>> on has no significant impact on system useability. Why not, for heavens
>> sake?
>>
>> Disused accounts represent a serious security problem, especially with
>> many
>> sites now granting remote access, thus there may be any number of
>> remotely-accessible accounts lying open for which the user has long-since
>> left the company, but for which the personnel dept just plumb forgot to
>> tell
>> I.T. about. Yet, Windows provides NO way of closing accounts which have
>> not
>> been used for a substantial time, which would seem to be one of the most
>> sensible and basic precautions to take against this occurrence.
>>
>> The other side of this is that despite its laxness in other respects,
>> Windows sets a 42-day password-expiry policy, and worse, does so
>> 'silently'
>> without telling anyone it's done so. This is extremely bad.
>>
>> I've had cases where laptops in overseas locations have unexpectedly
>> demanded a password-change in situations where there was no way to rejoin
>> the
>> domain within the time limit. This effectively 'bricks' the laptop until
>> it
>> can be shipped back to base. Highly embarrassing for me, and could have
>> cost
>> the company an international deal.
>>
>> It's time someone persuaded MS to see sense over these poorly thought-out
>> security policies.
>>
>> 1. Ditch password-expiry, or at least WARN the user that it exists, right
>> from first logon. (timebomb icon in sytem tray?)
>>
>> 2. Set password-lockout (dictionary-attack protection) ON by default.
>>
>> 3. Provide a means to identify/close disused accoutns.
>>
>>
>> Just my two cents worth.
>>
Microsoft servers, never saw it arrive there...}
Account lockout is a poor substitute for good passwords -- and is one of the
most expensive security features you can use. Let's think about this by
considering the threat. What threat does account lockout (attempt to)
mitigate? Password guessing. How can you make password guessing attacks
become useless for an attacker? Two ways: implement lockouts or use good
(meaning long) passwords.
Consider the first choice, account lockouts. The typical cost to an
organization to reset locked accounts is US$75 per help desk call. In a
medium or large organization, this can become a very high monthly
maintenance cost. In nearly all instances, the call results from users
locking themselves out, not users encountering locked out accounts because
some bad guy was trying to guess passwords. Account lockouts have one
more -- very bad -- problem: they *create* opportunities for bad guys to
conduct denial-of-service attacks against accounts or entire domains! Even
if you use a timed unlock of, say, 15 minutes, then the attacker can write
his script to churn through thousands of bogus logon attempts every 15
minutes 2 seconds. So, contrary to your claim, enabling this setting
actually can have significant impact on usability.
Account lockout is there for people who absolutely need it. But I can't
think of any instance where this is true. Instead, have a policy that
requires simple passwords at least 15 characters long. Forget about
complexity rules that force people to write down passwords. A simple
15-character passphrase (think short sentence) is easy to remember, quick to
type, and far stronger than any short complex password. A passphrase like
this will withstand any kind of automated password attack, including those
based on rainbow tables. And you can even use a method that helps you
remember unique phrases for each site, if you wish:
* web mail: "my dog and i got the mail"
* shopping: "my dog and i bought some stuff"
* office: "my dog and i went to work"
* photo site: "my dog and i admired some art"
This is why we disable account lockout by default. There are much better --
and much less expensive -- ways to mitigate the threat.
You're right, there's no built-in method to automatically disable unused
accounts. A variety of third-party products can provide you with this
functionality. I suspect some of them might be free, perhaps simple scripts
even. I tried searching on "automatically disable unused accounts" and saw a
few hits that looked promising. This particular function, however, rightly
belongs in the HR process. A number of customers I've spoken with have
automated the account creation/disablement/deletion process, incorporating
it into HR systems. When a new user is hired, the account is created when
the user departs, the account is disabled some time later, it's deleted.
The HR systems take care of this, not domain or enterprise administrators. I
wrote more about this subject here:
http://blogs.technet.com/steriley/archive/2007/05/31/when-you-say-goodbye-to-an-employee.aspx
Password expiration is an important setting for everyone. It mitigates two
threats: employees sharing passwords and bad guys discovering passwords.
Because we can eliminate the second threat using long simple passphrases as
I described above, then we have only one remaining threat: password sharing.
Your estimation of how prevalent this threat is in your environment will
guide you toward choosing an expiration time that works for you. 42 days is
a reasonable default our own corpnet uses 70 days. My experience with most
customers shows that password sharing isn't a problem. So for those who do
enforce long simple passphrases, I suggest that a reasonable default for
expiration is 120 days.
Windows begins notifying you 14 days before your password expires. You can
change this time period through group policy. I was in a similar situation
recently. Last month my domain password expired while I was in Australia for
TechEd there. I could continue to log on to my laptop with cached
credentials (so I'm not sure why you say your laptops become bricked?), but
couldn't use Outlook Web Access or RPC+HTTP of course. So I connected to a
Terminal Server computer we have on the Internet, logged on there, and
changed my password.
--
Steve Riley
steve.riley@microsoft.com
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com
>
>
> "Anteaus" <Anteaus@discussions.microsoft.com> wrote in message
> news:8303A854-B8AC-4AA9-9B4C-CA68C2374739@microsoft.com...
>> Not a solution, but I 've always thought Windows' default security
>> policies
>> were daft, what with having faddist password-change requirements, yet NO
>> protection against dictionary attack, and NO way of identifying or
>> closing
>> disused accounts.
>>
>> It stands to reason that any system which permits remote access MUST have
>> a
>> limit to the number of password-entry attempts in a given period,
>> otherwise a
>> correct guess is inevitable given enough time. Yet, while windows has
>> this
>> capability it's (inexplicably) turned off by default. Even though
>> turning it
>> on has no significant impact on system useability. Why not, for heavens
>> sake?
>>
>> Disused accounts represent a serious security problem, especially with
>> many
>> sites now granting remote access, thus there may be any number of
>> remotely-accessible accounts lying open for which the user has long-since
>> left the company, but for which the personnel dept just plumb forgot to
>> tell
>> I.T. about. Yet, Windows provides NO way of closing accounts which have
>> not
>> been used for a substantial time, which would seem to be one of the most
>> sensible and basic precautions to take against this occurrence.
>>
>> The other side of this is that despite its laxness in other respects,
>> Windows sets a 42-day password-expiry policy, and worse, does so
>> 'silently'
>> without telling anyone it's done so. This is extremely bad.
>>
>> I've had cases where laptops in overseas locations have unexpectedly
>> demanded a password-change in situations where there was no way to rejoin
>> the
>> domain within the time limit. This effectively 'bricks' the laptop until
>> it
>> can be shipped back to base. Highly embarrassing for me, and could have
>> cost
>> the company an international deal.
>>
>> It's time someone persuaded MS to see sense over these poorly thought-out
>> security policies.
>>
>> 1. Ditch password-expiry, or at least WARN the user that it exists, right
>> from first logon. (timebomb icon in sytem tray?)
>>
>> 2. Set password-lockout (dictionary-attack protection) ON by default.
>>
>> 3. Provide a means to identify/close disused accoutns.
>>
>>
>> Just my two cents worth.
>>