On password expiration

Hi,

In another group I posted a question on security for some of our
external users. They will access a messaging system (not MS Exchange)
and I wanted to set their passwords to expire every N days.

Lots of admins on that group argue that this is an evil thing. If user
Joe already has a secure password it is evil to make him change it and
possibly come up with a weaker password after N days.

The consequences for my users on this system may be extreme if the
passwords are compromised.

How do you argue, to expire or not expire - that's the question.

Martin S

Shenan
Fri Mar 31 01:34:01 CST 2006

Shieldfire wrote:
> In another group I posted a question on security for some of our
> external users. They will access a messaging system (not MS
> Exchange) and I wanted to set their passwords to expire every N
> days.
> Lots of admins on that group argue that this is an evil thing. If
> user Joe already has a secure password it is evil to make him
> change it and possibly come up with a weaker password after N days.
>
> The consequences for my users on this system may be extreme if the
> passwords are compromised.
>
> How do you argue, to expire or not expire - that's the question.


Expire. The longer a password is the same, the greater chance it can be
compromised.
As far as making a less complicated password - that all depends on your
complexity requirements.

--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html

Roger
Fri Mar 31 07:58:48 CST 2006

That is a difficult case to argue, and one needs to include
complexity of password used by the users, the education
of the users relative to "good" passwords and their habit
of complying with that education.
Just settings the built-in complexity does not guarantee
"good" passwords, ex. Password1

One aspect of the argument is that frequent pwd
change encourages people to write the pwd down
in a handy location. On the other side is the at times
hand wavy "calculation" of how long a pwd takes to
fall (to what, brute force or dictionary) attack. The
assumption is that this time grows as the length grows,
and that forcing more frequent change reduces risk of
a successful password guessing attempt. Frankly,
with use only of the exposed authentication interfaces,
guessing great, or even good, passwords is not high,
at least not before the attempts are noticed.

What I consider the best case for more frequent
change is that, given users lack of using "good" and
long passwords (pass phrases), there is a risk of a
password becoming compromised. Forcing more
frequent change of the password limits the usefulness
of any compromised passwords to a shorter period
(keep in mind that a compromised acct/pwd will be
used to access what it is allowed, which both defines
the scale of loss and also illustrates how it is unlikely
that such use would be noticed as it is not outside of
the expected use pattern).


However, I am wondering why you are concerned.
Since there is only one account policy per domain,
you are either getting ready to change this for all of
the accounts in the domain, or these users are from
a different domain. If from a different domain, then
you have a pretty good means for restricting their
scope of potential compromise since you only have
to be concerned with explicit grant to group of which
they are members, or to Authenticated Users, but
not with all the default grants involving (directly or
indirectly) Domain Users.

"Shieldfire" <shieldfire@newsgroups.nospam> wrote in message
news:eUS909IVGHA.2492@TK2MSFTNGP11.phx.gbl...
> Hi,
>
> In another group I posted a question on security for some of our external
> users. They will access a messaging system (not MS Exchange) and I wanted
> to set their passwords to expire every N days.
>
> Lots of admins on that group argue that this is an evil thing. If user Joe
> already has a secure password it is evil to make him change it and
> possibly come up with a weaker password after N days.
>
> The consequences for my users on this system may be extreme if the
> passwords are compromised.
>
> How do you argue, to expire or not expire - that's the question.
>
> Martin S

Shieldfire
Fri Mar 31 08:16:47 CST 2006

Roger Abell [MVP] wrote:

> What I consider the best case for more frequent
> change is that, given users lack of using "good" and
> long passwords (pass phrases), there is a risk of a
> password becoming compromised. Forcing more
> frequent change of the password limits the usefulness
> of any compromised passwords to a shorter period

Yes that is my take on it as well. One argument goes that the schedule
wouldn't catch that anyway (if the compromise occurs on day N and the
schedule says "change on N + 12 days" the damage is already done.


> However, I am wondering why you are concerned.
> Since there is only one account policy per domain,

Yes, but this is - as I indicated in the question - not a MS system.
So the messaging system doesn't make use of AD domains and settings
therein. It was more like a general question.
(We might in the future make use of the AD-compatibility modules available).

Martin S

Roger
Sat Apr 01 02:15:04 CST 2006

a tad more . . .
"Shieldfire" <shieldfire@newsgroups.nospam> wrote in message
news:OVmUl2MVGHA.5332@TK2MSFTNGP10.phx.gbl...
> Roger Abell [MVP] wrote:
>
>> What I consider the best case for more frequent
>> change is that, given users lack of using "good" and
>> long passwords (pass phrases), there is a risk of a
>> password becoming compromised. Forcing more
>> frequent change of the password limits the usefulness
>> of any compromised passwords to a shorter period
>
> Yes that is my take on it as well. One argument goes that the schedule
> wouldn't catch that anyway (if the compromise occurs on day N and the
> schedule says "change on N + 12 days" the damage is already done.
>

Indeed.
But the really important update to the docs being
watched might be on day 13.

>
>> However, I am wondering why you are concerned.
>> Since there is only one account policy per domain,
>
> Yes, but this is - as I indicated in the question - not a MS system.

You are right, I overlooked that part.

Which reminds me of something significantly different between MS
based and Unix based systems - the "richness" of the group and
hence authorization system. With MS based systems it can be a
little easy to overlook, or fail to fully assess, the scope of impact
from compromise of a specific account. Instead of grants to an
account and a primary group one has a situation where UserX's
account might have broad-reaching accesses under unexpected
(to causual look) grants.

> So the messaging system doesn't make use of AD domains and settings
> therein. It was more like a general question.
> (We might in the future make use of the AD-compatibility modules
> available).
>
> Martin S

Ian
Sun Apr 02 00:46:02 CST 2006

I'm very much against it.

1. It forces users to have non-memorable passwords, which means they end up
on post-its stuck to the VDUs. Security=0.00

2. The dialog doesn't make it clear WHAT password they have to change (or
even what program is producing the pop-up) A lot of users change their email
or ISP password thinking this is what it means.

3. For roving users, if the 'timebomb' goes-off in a remote location, and
the user cannot make the change or fumbles it, the result could be very
costly, for example a sales trip having to be cancelled and the laptop taken
back to the domain for resetting.

4 If a hacker has my password, then he is going to wait 42 days before he
steals or trashes my data. Of course he is. They always do that. Don't they?

5 There is a serious bug in the password-expiry code, in that it fails to
check the policies in force - to confirm that the user has the necessary
rights to change the password - before forcing a change. If the user has no
such rights, then it simply tells them to do the impossible, and locks them
out when they don't comply.

Perhaps the craziest thing is that while Windows has this troublesome
'password-timebomb' built-in right out of the box, it doesn't have any
timeout-mechanism to close disused accounts. Disused accounts are a serious
security weakness, yet AFAIK the only way they can be closed is by manual
auditing.

Dave
Sun Apr 02 22:33:17 CDT 2006

Ian wrote:
> I'm very much against it.
>
> 1. It forces users to have non-memorable passwords, which means they end up
> on post-its stuck to the VDUs. Security=0.00

It is possible to munge a memorable password into something a little more random.

>
> 2. The dialog doesn't make it clear WHAT password they have to change (or
> even what program is producing the pop-up) A lot of users change their email
> or ISP password thinking this is what it means.
>
> 3. For roving users, if the 'timebomb' goes-off in a remote location, and
> the user cannot make the change or fumbles it, the result could be very
> costly, for example a sales trip having to be cancelled and the laptop taken
> back to the domain for resetting.
>
> 4 If a hacker has my password, then he is going to wait 42 days before he
> steals or trashes my data. Of course he is. They always do that. Don't they?
>
> 5 There is a serious bug in the password-expiry code, in that it fails to
> check the policies in force - to confirm that the user has the necessary
> rights to change the password - before forcing a change. If the user has no
> such rights, then it simply tells them to do the impossible, and locks them
> out when they don't comply.
> Perhaps the craziest thing is that while Windows has this troublesome
> 'password-timebomb' built-in right out of the box, it doesn't have any
> timeout-mechanism to close disused accounts. Disused accounts are a serious
> security weakness, yet AFAIK the only way they can be closed is by manual
> auditing.
>

Let's keep the number of virtual booby-traps to a minimum if we can.

I wouldn't want closing disused accounts to be too automatic. But that decision
just might be different in a multi-user environment.



--

Dave Keays

dstynchula
Mon Apr 03 14:51:58 CDT 2006

Hi Martin,

If you are very concerned about the security of the system, simply
forcing your users to change their passwords every X number of days is
not going to be a viable security strategy. That's not to say it's
not a really good idea, it's just that some user education is in
order. The average user has no idea about information security. In
order to secure the system, if the data is as sensitive as you have
suggested, I would suggest implementing an account inactivity
expiration time, requiring an admin to re-enable accounts that have
been dormant for X numbers of days, an account lockdown policy to
prevent brute force attacks, and depending on how secure your
environment needs to be, an access log with someone assigned to audit
login attempts periodically.

In addition, you should set some expectations regarding the handling of
data as a personnel/management issue. For instance implementing an
organizational policy prohibiting employees from writing down their
passwords will mitigate the "sticky-notes on the VGA monitor"
possibility. Ultimately, some employees may choose to disregard this
instruction, but at that point you will have some accountability
options.

Best Regards,

Dan Stynchula

Patrick
Tue Apr 04 09:24:22 CDT 2006

"Shieldfire" <shieldfire@newsgroups.nospam> wrote in message
news:eUS909IVGHA.2492@TK2MSFTNGP11.phx.gbl...
> Hi,
>
> In another group I posted a question on security for some of our external
> users. They will access a messaging system (not MS Exchange) and I wanted
> to set their passwords to expire every N days.
>
> Lots of admins on that group argue that this is an evil thing. If user Joe
> already has a secure password it is evil to make him change it and
> possibly come up with a weaker password after N days.
>
> The consequences for my users on this system may be extreme if the
> passwords are compromised.
>
> How do you argue, to expire or not expire - that's the question.
>
> Martin S


I can see this from both aspects. As someone who is security concious, I
agree with the expiration and the complexity standards. As an end-user in a
corporation (where I have no IT related duties, other then using the
computer for e-mail and training), I can see where the other end-users
complain about the passwords.

But, I will say this. Those same users who complain about the passwords,
have grown used to the setup. So, every 90 days, they dilligently change
their password, and gripe for a few days. Then they go on with their lives.

As for writing the password down, yes it's vulerable to thieves. However, I
would think that unless they write down their username as well (and to an
extent their corporation login information), it's going to be almost
pointless to anyone outside of the corporation. I could, and probably am,
wrong on this though.

In the end, if you're going to implement this, I would recommend that you
suggest to your end-users this policy (for simplicity in their lives only).
Every --N days, when they change their password at the office, they should
go home and change their user password on their home computer to the same
thing. This way, they're LESS apt to forget the password, and LESS apt to
have it written down somewhere. They'll have to weigh the risks that
someone gets into their home computer and realizes that's the same password
as their work one. But, I would imagine that if someone gains access to
their home and their home computer (outside of family or friends of kids,
etc.), the fact that the person has their work password is going to be low
on their concerns.

Just my three cents worth (would have been two, but I'm long-winded).
Patrick.

--
Smile... Someone out there cares deeply for you.

Shieldfire
Wed Apr 05 04:24:23 CDT 2006

Thanks for you input.
What we did was to make secure passwords
http://www.winguides.com/security/password.php

and set them for them. When we see them next time, they be able to chose
their own password following the same standard.

Martin S

alun
Sun Apr 09 20:49:29 CDT 2006

In article <1144093918.401539.202300@u72g2000cwu.googlegroups.com>,
dstynchula@gmail.com wrote:
>In addition, you should set some expectations regarding the handling of
>data as a personnel/management issue. For instance implementing an
>organizational policy prohibiting employees from writing down their
>passwords will mitigate the "sticky-notes on the VGA monitor"
>possibility. Ultimately, some employees may choose to disregard this
>instruction, but at that point you will have some accountability
>options.

Sticky notes on the monitor are generally a bad idea.

But there are other places to write passwords down that are significantly
better.

Personally, I carry a special device with me at all times, whose purpose is to
secure pieces of paper and plastic that have a perceived value to me, and
facilitate my access to secured resources.

It's called a wallet, and it has been many years since I last mislaid one or
had it purloined. The pieces of paper and plastic that are already in there
are nice and safe, and when I lose them, I spend a little time ensuring that
they are no longer of use in accessing my secured resources.

Passwords are no different. I write them down, those that I cannot remember,
and I carry them around in my wallet. If I lose my wallet, I will include my
domain's administrators in the list of people I will be asking to reset my
credentials.

Alun.
~~~~

[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Find us at http://www.wftpd.com or email
23921 57th Ave SE | alun@wftpd.com.
Washington WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.