RE: password policy - alternate lockout mechanism

["Clowser, Jeff" <jeff_clowser@fanniemae.com>]

> Aravind Gottipati wrote:
> > On Sun, Jul 12, 2009 at 10:53 PM, Howard Chu<hyc@symas.com>  wrote:
> >> Fix the real problem, not just the symptom. The approach 
> you're pushing for
> >> is just putting a bandaid on a problem, not fixing it. 
> This may be how other
> >> folks handle their software design problems, but it just 
> doesn't fly for
> >> security issues.
> >
> > Howard,
> >
> > You are right that it's not correct for apps to continue trying to
> > authenticate with an incorrect password, or for them to 
> fail silently.
> >   In a perfect word this would not happen.  Unfortunately, we can't
> > control all these apps or user's behaviors.  My choices are 
> to either
> > ignore the problem and lock folks out after X failed 
> attempts (whether
> > real of from faulty apps), or, not even implement any sort of
> > lockouts.  I am not sure how else I can explain this to 
> you, but it's
> > a real problem and saying, "fix your apps" doesn't always work.
> 
> Regardless, your security model is broken. Further weakening 
> the guarantees of 
> the existing policy is only going to make it more broken, not 
> less broken.
> 
> Think about what your actual problem is, and fix it. You 
> haven't done any 
> clear thinking here yet.
> 
> Your problem is that you have applications which essentially 
> render your 
> policy useless. There is no other word for this type of 
> application other than 
> "security risk." The correct solution is to mitigate that 
> risk, not to break 
> your policy for all the other well-behaved users. In this 
> case, if you cannot 
> fix the applications, then change the credentials that the 
> apps authenticate 
> with. Give each user an app-specific ID and password, one 
> that is very strong 
> and has a different expiration schedule. (Since the 
> credential is cached in 
> the app anyway, it doesn't matter if it's huge and 
> inconvenient to enter, the 
> user only has to do it once.) Limit the privileges of this 
> app-specific 
> credential so that it is only valid for that particular application.
> 


Just want to make a few points here:

- I think we can all agree that these apps are broken and that the first
and best approach is to try to get these apps fixed. In an ideal world,
that would be the only solution needed.  Unfortunately, most of us don't
live in an ideal world, and it's simply not possible to fix this in
every application across an enterprise, or to select only apps that do
passwords right (generally, that doesn't even make it on the
requirements list...).  As an alternative, it is reasonable to find a
way to deal with it at a centralized point - the directory.  That's part
of the benefit of centralizing things.

- Creating separate user accounts for separate apps a user uses defeats
many of the benefits of a centralized directory.  One security benefit
being that a user has one account/id for all apps, such that deleting
that one account entry takes away all their access.  If we start
creating multiple account entries for users, you lose this and risk
"forgetting" to terminate one of their many accounts, making this
multiple IDs for each user idea more of a security risk, not less.  May
as well go back to decentralizing the directory back into each app.  It
may not be an ideal place to fix it, but it is a practical one.  And
yes, it has to be separate accounts/entries, since these apps are doing
binds to the directory to auth (i.e. can't create separate attributes
for custom ID's/passwords).

- Consider this example - the place I run into this most often is our
Internet proxies, which are password protected.  There are many apps a
user uses that connects through the proxy (which in turn auths against
ldap) to get some kind of content or update.  Some of these (broken)
apps provide users an option to save the password, and when they do (not
that I recommend this behavior, but I can't stop them), it tries
repeatedly to get updates/content using the old password after a user
changes their password.  If I set a unique id for the proxy for these
apps, the user would have to use this for *all* their apps that access
the web.  I could allow both this unique id and their "normal" id access
to the proxy, but the end result is that users would forget this less
used id and just enter their "normal" id and password everywhere, which
puts us back to the original problem. (And please don't say this is a
user training issue - we all know that's rarely effective in the real
world...)  So, this is not really a practical suggestion.  

- The entire point of locking an account after some number of failed
attempts is for one and only one purpose:  To stop a brute force attack
on a users password, which to succeed means trying many *different*
passwords until the correct one is guessed.  Retrying the same wrong
password over and over will never succeed, so is not a security risk.
So the *concept* of ignoring repeats of a wrong password introduces no
security risk.  I don't see how this in any way weakens any guarantee in
the security policy.

- So, the only "risk" is that of storing the hash of the failed
attempts.  I've seen arguments, the strongest of which is that this is
bad because the failed password they tried *might* be used elsewhere.
But consider that password history *is* supported.  In my experience,
users tend to rotate through a set of passwords they can remember, and
use the same passwords on multiple systems, so it is far more likely
that the passwordhistory will contain a password that they use
elsewhere.  This failed password hash cache (for lack of a better term)
may also store passwords used elsewhere as a result, but will also
include finger fumbles, etc that are not used anywhere.  This password
cache is also typically less long lived than passwordhistory (it goes
away with a successful bind). So I'd argue that this password cache is
*less* of a risk than passwordhistory, which is deemed acceptable.   If
these failed password cache attributes are properly protected by aci's,
etc, they are just as safe (or more so) than passwordhistory.  Some may
argue that this is a user problem (using the same password between
systems) and the fix is user education, but remember:  we live in the
real world, so nothings gonna stop this user behavior.

- If we want to be really paranoid, in cases where someone accidentally
passes a password for another system to my directory, from a users POV
they have no idea what my server did with that password.  So the mere
fact that they sent it to my directory means I *could* conceivably have
it.  Whether I store it in a cache to prevent false lock events or not
is irrelevant as far as they know - they've sent their password to
someplace that shouldn't have it, and that someplace has now "seen"
their password for the other system.  Plus, without knowing what that
other system is or the userid on that system, the password doesn't
really help me.  I'd probably be far more likely to break into other
systems trying the same id (or email addr) and password they have in my
directory on these other systems. (Again, users don't always do smart
things.  Security policy can only account for stupid user behavior to a
point...)

- The mozilla sponsored ppolicy enhancement makes this duplicate failed
password check optional.  Those that feel it's too much of a security
risk can leave it off and use the old behaviour.  Those that feel
comfortable using it can do so.


> The first principle of good security design is to have a 
> clearly defined 
> policy with no exceptions. 

But we have that.  It is:

  Lock any account where more than x consecutive unique failed passwords
attempts are seen.

This being changed from:

  Lock any account where more than x consecutive failed passwords
attempts are seen.

So there is still a clear policy, and no exceptions.  Introducting the
"unique" part in concept poses no risk, as shown above.


 - Jeff