Password is passed Multiple times per thread?

Hello,

I was presented an MS article that stated that when a person submits their
password/credentials in conjunction with an executable, that the passing of
the credentials is multiplied by the threads underneath the executable
process. Is this so? We have had quite a few accounts that have locked out
from a single bad password entry and our limit is set to 5

If anyone has any ideas or could point out an article or white paper which
discusses this issue, I would be most appreciative.

Karl
Fri May 12 15:01:11 CDT 2006

Microsoft does not currently recommend setting account lockout threshold to
just 5. They now argue, and I feel rightly so, that it is better to bump
that number up to, say 10 or 20 or even more. The justification is that the
organization increases its risk of users not being able to work and the lost
time and money incurred by additional help desk requests, and that this
increased risk more than outweighs the relatively small benefit of having
such a restrictive account lockout threshold.

It is true that in some situations, Windows will retry a failed password
several times in the space of a second. I have seen this result in account
lockouts.


<-> wrote in message news:uEg$gyfdGHA.3348@TK2MSFTNGP03.phx.gbl...
> Hello,
>
> I was presented an MS article that stated that when a person submits their
> password/credentials in conjunction with an executable, that the passing
of
> the credentials is multiplied by the threads underneath the executable
> process. Is this so? We have had quite a few accounts that have locked
out
> from a single bad password entry and our limit is set to 5
>
> If anyone has any ideas or could point out an article or white paper which
> discusses this issue, I would be most appreciative.
>
>

->
Fri May 12 15:19:15 CDT 2006

Thanks so much Kevin,

I agree, but people see double digit account lockout thresholds and have
this gut reaction that it's so "loose." Anyway, I'm digging around for that
"multiple thread" article that will prove it; it's like one thread passes
Kerberos, the other thread passes Netlogon, something to that effect. I'm
going to present that to them when I find it and that should be pretty rock
solid.

Thanks again


"Karl Levinson, mvp" <levinson_k@securityadmin.info> wrote in message
news:%23XjGY7fdGHA.3352@TK2MSFTNGP03.phx.gbl...
> Microsoft does not currently recommend setting account lockout threshold
> to
> just 5. They now argue, and I feel rightly so, that it is better to bump
> that number up to, say 10 or 20 or even more. The justification is that
> the
> organization increases its risk of users not being able to work and the
> lost
> time and money incurred by additional help desk requests, and that this
> increased risk more than outweighs the relatively small benefit of having
> such a restrictive account lockout threshold.
>
> It is true that in some situations, Windows will retry a failed password
> several times in the space of a second. I have seen this result in
> account
> lockouts.
>
>
> <-> wrote in message news:uEg$gyfdGHA.3348@TK2MSFTNGP03.phx.gbl...
>> Hello,
>>
>> I was presented an MS article that stated that when a person submits
>> their
>> password/credentials in conjunction with an executable, that the passing
> of
>> the credentials is multiplied by the threads underneath the executable
>> process. Is this so? We have had quite a few accounts that have locked
> out
>> from a single bad password entry and our limit is set to 5
>>
>> If anyone has any ideas or could point out an article or white paper
>> which
>> discusses this issue, I would be most appreciative.
>>
>>
>
>

kj
Fri May 12 15:51:20 CDT 2006

There are many articles and many issues with a lockout value this low,
depending upon the environment.

Generally this way too low a value. 15 to 20 would likely be a better choice
to thwart attempted password cracking.
( combined of course with a good password policy and auditing )

--
/kj
<-> wrote in message news:uEg$gyfdGHA.3348@TK2MSFTNGP03.phx.gbl...
> Hello,
>
> I was presented an MS article that stated that when a person submits their
> password/credentials in conjunction with an executable, that the passing
> of the credentials is multiplied by the threads underneath the executable
> process. Is this so? We have had quite a few accounts that have locked
> out from a single bad password entry and our limit is set to 5
>
> If anyone has any ideas or could point out an article or white paper which
> discusses this issue, I would be most appreciative.
>

Steven
Fri May 12 18:18:46 CDT 2006

Why would they think that is so loose? Do they think it is possible that a
users password can be guessed in 20 tries? If so that is pretty remarkable
and they must be used to managing networks were very weak passwords are
allowed. If strong passwords are enforced on the domain then a threshold of
fifty [which is what Microsoft recommends] for attempts will adequately
deter brute force password attacks. If you want really strong passwords then
enforce password complexity and have minimum password length of 15
characters and train users to think of pass phrases where they can and
should leave spaces in there pass phrase. A pass phrase such as I forget my
stupid password! would be an extremely strong password. Social engineering
attacks and keyboard loggers [software/hardware] are much bigger threats
then a "loose" account lockout policy. --- Steve


<-> wrote in message news:OrGdYFgdGHA.1324@TK2MSFTNGP04.phx.gbl...
> Thanks so much Kevin,
>
> I agree, but people see double digit account lockout thresholds and have
> this gut reaction that it's so "loose." Anyway, I'm digging around for
> that
> "multiple thread" article that will prove it; it's like one thread passes
> Kerberos, the other thread passes Netlogon, something to that effect. I'm
> going to present that to them when I find it and that should be pretty
> rock
> solid.
>
> Thanks again
>
>
> "Karl Levinson, mvp" <levinson_k@securityadmin.info> wrote in message
> news:%23XjGY7fdGHA.3352@TK2MSFTNGP03.phx.gbl...
>> Microsoft does not currently recommend setting account lockout threshold
>> to
>> just 5. They now argue, and I feel rightly so, that it is better to bump
>> that number up to, say 10 or 20 or even more. The justification is that
>> the
>> organization increases its risk of users not being able to work and the
>> lost
>> time and money incurred by additional help desk requests, and that this
>> increased risk more than outweighs the relatively small benefit of having
>> such a restrictive account lockout threshold.
>>
>> It is true that in some situations, Windows will retry a failed password
>> several times in the space of a second. I have seen this result in
>> account
>> lockouts.
>>
>>
>> <-> wrote in message news:uEg$gyfdGHA.3348@TK2MSFTNGP03.phx.gbl...
>>> Hello,
>>>
>>> I was presented an MS article that stated that when a person submits
>>> their
>>> password/credentials in conjunction with an executable, that the passing
>> of
>>> the credentials is multiplied by the threads underneath the executable
>>> process. Is this so? We have had quite a few accounts that have locked
>> out
>>> from a single bad password entry and our limit is set to 5
>>>
>>> If anyone has any ideas or could point out an article or white paper
>>> which
>>> discusses this issue, I would be most appreciative.
>>>
>>>
>>
>>
>
>
>

wickydog
Fri May 12 23:29:01 CDT 2006

I will recommend that the password thread should have a greater value so
security in the domain enhance. However, we can make the logout duration
shorter so it will make the administration work lighter. However, it still
have the security concern.

"kj" wrote:

> There are many articles and many issues with a lockout value this low,
> depending upon the environment.
>
> Generally this way too low a value. 15 to 20 would likely be a better choice
> to thwart attempted password cracking.
> ( combined of course with a good password policy and auditing )
>
> --
> /kj
> <-> wrote in message news:uEg$gyfdGHA.3348@TK2MSFTNGP03.phx.gbl...
> > Hello,
> >
> > I was presented an MS article that stated that when a person submits their
> > password/credentials in conjunction with an executable, that the passing
> > of the credentials is multiplied by the threads underneath the executable
> > process. Is this so? We have had quite a few accounts that have locked
> > out from a single bad password entry and our limit is set to 5
> >
> > If anyone has any ideas or could point out an article or white paper which
> > discusses this issue, I would be most appreciative.
> >
>
>
>