[cryptography] Password non-similarity?

Kevin W. Wall kevin.w.wall at gmail.com
Mon Jan 2 18:51:17 EST 2012

On 2012/1/2 lodewijk andré de la porte <lodewijkadlp at gmail.com>:
> The reason for regular change is very good. It's that the low-intensity
> brute forcing of a password requires a certain stretch of time. Put the
> change interval low enough and you're safer from them.

This may make sense in specific cases, but in the general case,
say for web sites that have a large # of public users, there are other
things that this has to be weighed against. Specifically consider
cases where users might only login once a month to pay a bill. If
you require those users to change their passwords every 30, 60,
or 90 days, they probably will never actually have time to learn it.
And since we've tried to teach people not to write down their passwords
on PostIt notes, etc. many of these users don't write them down
at all.

So the end result is that many of these types of users frequently
forget their passwords, because they only use them 2 or 3 times
before they have to change them again. So that has the undesirable
effect of increasing calls to the helpdesk to have users' passwords
reset.  To drive this additional helpdesk cost down, IT then decides
to implement a "I forgot my password" mechanism that is generally
based one some set of trivial Q & A such as "What is your favorite
sports team?" or "Where did you attend elementary school?", etc.
thus causing over major security issues.

So I would conjecture, at least in cases like this where users only
login infrequently, that the password change policy every N days
be done away with, or at the very least, we make N something
reasonably long, like 365 or more days.

That's why I've said and will say again, that your security policies
should be driven by your specific threat model. Unfortunately, most
companies don't do this. Instead that they just perpetuate the myth
that everyone should be required to change their password every N
days because this is obviously best security practice for everyone.
It may be for your specific threat model, but it also might not be.

> We've had someone talk on-list about a significant amount of failed remote
> ssh login attempts. Should he chose not to force user to change their
> passwords they wouldn't. And the likelyhood of a successfull login
> would improve with the years (given coordination) to somewhere above the
> admin's comfort zone.
> The timeframe in which a password has to change also limits the maximum time
> exposed once someone has cracked it. This is relevant when the adversary
> needs multiple opportunity's to coincide. The amount of time it'll have
> access without triggering resource-counting or other "suspicious behavior"
> alarms becomes limited, as changing a password would either lock him or the
> legitimate user out.

Although requiring the use of SSH public/private keys probably would
be better way to go here. The big problem here is for *nix systems
at least, even if you remember your password and could change it,
trying to remember 20+ ferent passwords for 20+ different servers,
all which expire at different times is, at a minimum, a major pain in
the ass, and generally will cost you in terms of requiring a password
having to be reset by some system administrator plus all the helpdesk

> For most systems though, it's a complete waste of time.


Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein

More information about the cryptography mailing list