Expire or not expire?

[Shurick]

Hello,

Help me to solve this dilema. What scenario is more secure?

1. I apply policy to change their passwords every 2 months.
2. I apply policy that passwords are never expired.

In first scenario half of users will store their passwords on stickers and
that confuse me.

Thank for any suggest!

 

[Shenan Stanley]

Shurick wrote:
> Hello,
>
> Help me to solve this dilema. What scenario is more secure?
>
> 1. I apply policy to change their passwords every 2 months.
> 2. I apply policy that passwords are never expired.
>
> In first scenario half of users will store their passwords on
> stickers and that confuse me.

If you never change passwords - you make it easier for someone attempting to
hack your system to do so as they have all the time in the world to hack
MANY users passwords and utilize them as necessary to further their needs.
If you set them to expire every 60 days - you may have a few people that
actually use post-it notes - but more likely you'll end up having people
make passwords like, "ThisIsMyPassword1" and changing it to
"ThisIsMyPassword2" in two months... Not that this is great - but not that
bad - at least they change.

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

 

[Shurick]

Hello, Shenan Stanley!
Thank you for answer!

Under "someone attempting to hack your system"
did you mean fitting of password?

I think that fitting is more contollable by different logs then passwords
that users write on his notes...

"Shenan Stanley" wrote:

> Shurick wrote:
> > Hello,
> >
> > Help me to solve this dilema. What scenario is more secure?
> >
> > 1. I apply policy to change their passwords every 2 months.
> > 2. I apply policy that passwords are never expired.
> >
> > In first scenario half of users will store their passwords on
> > stickers and that confuse me.
>
> If you never change passwords - you make it easier for someone attempting to
> hack your system to do so as they have all the time in the world to hack
> MANY users passwords and utilize them as necessary to further their needs.
> If you set them to expire every 60 days - you may have a few people that
> actually use post-it notes - but more likely you'll end up having people
> make passwords like, "ThisIsMyPassword1" and changing it to
> "ThisIsMyPassword2" in two months... Not that this is great - but not that
> bad - at least they change.
>
> --
> Shenan Stanley
> MS-MVP
> --
> How To Ask Questions The Smart Way
> http://www.catb.org/~esr/faqs/smart-questions.html
>
>
>

 

[Anteaus]

I have never understood Microsoft's policy of forcing password changes, and
on 2003 server of demanding passwords of insane complexity.

.....yet, of having a default which gives no protection against brute-force
attack. The first line of protection should be against brute-force attack,
and this requires that a bad-logon count and banning interval are set. If an
intruder can only enter (say) five passwords every fifteen minutes, then a
brute-force attack on even a weak password will take a very long time. Even
better is if the Admin is notified that repeated lockouts are happening, in
which case the brute-force attack is unlikely to get very far at all.

What's worse about the default is that it gives no indication of the
presence of the 'ticking password-bomb' on the computer until a few days
before expiry. This can cause major problems for overseas workers, since the
password cannot be changed away from the domain.

"Shurick" wrote:

> Help me to solve this dilema. What scenario is more secure?
>
> 1. I apply policy to change their passwords every 2 months.
> 2. I apply policy that passwords are never expired.

 

[jwgoerlich@gmail.com]

The first is more secure, particularly when coupled with training.
Provide your people with a simple way of generating password phrases
(e.g., come up with a saying or nursery rhythm and include dates as
spaces.) A password can be easy to remember and complex.

Also, watch your password length. 8 characters used to be long enough
to survive 60-days of brute forcing. With recent increases in hardware
and password cracking speeds, this is no longer the case. Try for
either a 10 or 12 character phrase.

J Wolfgang Goerlich

On Dec 17, 12:28 am, Shurick <Shur...@discussions.microsoft.com>
wrote:
> Hello,
>
> Help me to solve this dilema. What scenario is more secure?
>
> 1. I apply policy to change their passwords every 2 months.
> 2. I apply policy that passwords are never expired.
>
> In first scenario half of users will store their passwords on stickers and
> that confuse me.
>
> Thank for any suggest!

 

[Florian Frommherz [MVP]]

Howdie!

Anteaus schrieb:
> I have never understood Microsoft's policy of forcing password changes, and
> on 2003 server of demanding passwords of insane complexity.

Insane? Could you please elaborate what - with this complexity - is insane?

> .....yet, of having a default which gives no protection against brute-force
> attack. The first line of protection should be against brute-force attack,
> and this requires that a bad-logon count and banning interval are set. If an

It's not only attacks that come online where a guy sits in front of a
computer or queries AD for logon attempts - it's offline attacks as well
where you can re-calculate a user's passwords offline (without domain
machine and DC interaction) if the password is too short - given the
possibility you can sniff the network a little.

> intruder can only enter (say) five passwords every fifteen minutes, then a
> brute-force attack on even a weak password will take a very long time. Even

....if and only if the intruder tries that online.

> better is if the Admin is notified that repeated lockouts are happening, in
> which case the brute-force attack is unlikely to get very far at all.

A reporting mechanism would need a third party application, since WS
2003 doesn't support that by default.

> What's worse about the default is that it gives no indication of the
> presence of the 'ticking password-bomb' on the computer until a few days
> before expiry. This can cause major problems for overseas workers, since the
> password cannot be changed away from the domain.

14 days is a good time frame for people. Most enterprises use Exchange
or provide a VPN dial in mechanism which enables people to see when
their passwords expire. For those who have not, there's an option to
change the default reminder days count - but I agree with you,
off-the-road users are always a problem (not to stick with this issue,
only).


--
Microsoft MVP - Windows Server - Group Policy.
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.

 

[Kurt]

It is highly advised to enable password changes in your domain environment for user accounts vs. maintaining static passwords.
Sure, your users will grumble a bit having to pick new passwords and there is potential for "sticky notes"... However, at least any found sticky note passwords will not be valid for more than xx days per your password change policy.

If deployed correctly and with the proper support tools in place, rolling out a password change policy in an existing domain won't be as challenging as you think and will certainly improve your internal security.

Here are some suggestions for helping with your initiative:

1. Get senior management / exectuve buy-in before planning a password change environment. It's imperative that senior managers and/or executive staff are 100% on board with implementing a password change policy. Having support from the top makes implementing your change policy that much easier- Find out what password change term would be comfortable for them, 60 days, 90 days, etc... If you are working to meet PCI, HIPAA, GLB or SOX-related goals surrounding user account security you'll probably need to stick to 60 days at most.
If you are fortunate enough to not have to worry about compliance then the maximum age of user passwords is pretty much an internal desicion. You could start at say, 120 days and eventually shorten the policy to 60 days over the course of a year, after users become familiar with the change process.

2. Communicate to users before and during deployment. This is important and often overlooked by IT.
Before you roll out your password change policy, communicate openly to users about the upcoming password change policy via email and/or company meetings. Set expectations accordingly, answer questions, and generally explain to users why the policy is being implemented and how their part in the process will help ensure security of internal company assets. Users like to feel included, especially on things that will change the way they use company systems. Remember, you can't please everyone but even the grumblers will appreciate being informed.

3. Gain knowledge about how to properly implement a password change policy in an existing domain. If your password change policy is enabled without proper pre-planning, you're going to have a lot of upset users with expired passwords. Read our planning whitepaper which discusses a couple of password change deployment methods that will keep impact to your users at a minimum:
http://www.sysoptools.com/support.html#wp
You'll want to read #2.
Also read #1 and #5 which discuss the password policy settings, best practice / suggested settings, and how the password policy functions in Active Directory.

4. Use a good support tool to plan and support your password change deployment. Our software tool Password Reminder PRO is designed to automatically alert and remind users of upcoming password expirations in a reliable and friendly manner. You can choose when to have reminder sent to users in advance of password expiration, customize the reminder message and include instructions / support contact info / links to help docs / example of a proper password, etc.
In addition, you'll receive a daily report summary of users who'se password will expire soon, expired password accounts, potential problem accounts, etc.
You can use the built in Report Console to easily review all of your domain user accounts by "type" and identify possible account problems before deploying your domain change password policy.
Password Reminder PRO makes deploying and maintaining an internal change password policy significantly easier for both the end user and IT staff, and will help keep support calls surrounding expired passwords to a minimum, especially if you have a number of laptop, Outlook Web Access and VPN users.
Password Reminder PRO is totally free to use for two months, so try it out as part of your pre-deployment planning and see if you find value in using it.

5. Resign to the fact that the first two to three password change intervals will be the toughest on your user community and support staff. This is the "adjustment period" as users become accustomed to creating a new password every xx days. If you plan and implement your password change deployment properly, communicate effectively to users about the upcoming change, and set their expectations accordingly, you'll end up with a much easier job on your hands. While definitely not required, our Password Reminder PRO tool is specifically designed to ease the burden of deploying and maintaining a password change policy, and ensure success.

Happy Holidays and good luck whichever direction you decide-

Kurt L.
Senior Support Lead / MCSE / CCNP
SysOp Tools
www.sysoptools.com

Hello,

Help me to solve this dilema. What scenario is more secure?

1. I apply policy to change their passwords every 2 months.
2. I apply policy that passwords are never expired.

In first scenario half of users will store their passwords on stickers and
that confuse me.

Thank for any suggest!

 

[Kurt]

We totally understand this problem and have created a specific utility that resolves the notification issue to users. It's also extremely easy to set up and use, and does not require any VB, LDAP or scripting knowledge.
http://www.sysoptools.com

Happy Holidays-

Kurt L.
Senior Support Lead / MCSE / CCNP
SysOp Tools
www.sysoptools.com

Howdie!


> What's worse about the default is that it gives no indication of the
> presence of the 'ticking password-bomb' on the computer until a few days
> before expiry. This can cause major problems for overseas workers, since the
> password cannot be changed away from the domain. [/color]

14 days is a good time frame for people. Most enterprises use Exchange
or provide a VPN dial in mechanism which enables people to see when
their passwords expire. For those who have not, there's an option to
change the default reminder days count - but I agree with you,
off-the-road users are always a problem (not to stick with this issue,
only).


--
Microsoft MVP - Windows Server - Group Policy.
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.

 

[Kurt]

Anteaus-
Yes, it can be quite confusing and there are not a lot of good sources that clearly explain the Active Directoy password policy and settings.

Please read this white paper from Microsoft, which is probably the BEST ever on explaining the password policy settings and giving you some clear initial settings to work with.

http://www.sysoptools.com/support.html#wp
Download document #1, go to page 9 to view the table of recommended settings. If you fully read this document, you will completely understand how the policies function.

You may also wish to read document #5 which coveres how the policy functions in Active Directory and why you must define your password change policy settings in the default policy for the domain.

Happy Holidays-

Kurt L.
Senior Support Lead / MCSE / CCNP
SysOp Tools
www.sysoptools.com

I have never understood Microsoft's policy of forcing password changes, and
on 2003 server of demanding passwords of insane complexity.

.....yet, of having a default which gives no protection against brute-force
attack. The first line of protection should be against brute-force attack,
and this requires that a bad-logon count and banning interval are set. If an
intruder can only enter (say) five passwords every fifteen minutes, then a
brute-force attack on even a weak password will take a very long time. Even
better is if the Admin is notified that repeated lockouts are happening, in
which case the brute-force attack is unlikely to get very far at all.

What's worse about the default is that it gives no indication of the
presence of the 'ticking password-bomb' on the computer until a few days
before expiry. This can cause major problems for overseas workers, since the
password cannot be changed away from the domain.

"Shurick" wrote:

> Help me to solve this dilema. What scenario is more secure?
>
> 1. I apply policy to change their passwords every 2 months.
> 2. I apply policy that passwords are never expired.

 

[Anteaus]

"Florian Frommherz [MVP]" wrote:

> Insane? Could you please elaborate what - with this complexity - is insane?

The fact that the password is repeatedly rejected, but the system flatly
refuses to tell the user what they need to do to get a password accepted.
THAT is insane. Or, at least, unbelievable myopia on the part of the
designers.

> ....if and only if the intruder tries that online.

This raises two issues. Firstly, if someone is operating a wiretap on your
comms, then perhaps you have more to worry about than mere passwords. If you
think that is likely or possible, then you need a fully-encrypted comms
channel. Or, a change of carrier! I suppose a wiretap IS possible in a hotel
or the like in a lawless country, though I imagine it would be highly
unlikely between two Western ISPs.

Secondly, it raises questions as to the security of the password-handshake
process. If this is correctly designed it surely ought not to be possible to
see password-fragments in the data stream. If that IS possible by
straightforward packet-sniffing, then some more thought needs to be put into
the security of the base system.

 

[Ben M. Schorr, MVP]

I don't force password changes, generally. I prefer to force long pass
phrases and let people select their own pass phrases. That way they can
select things that are easy for them to remember and because the pass
phrases are long (15 characters+ generally) they are nearly impossible to
brute-force.

We also set the lockout policy so that an intruder could only brute force
attempt about 100 passwords in an hour. By the time an intruder
successfully brute forced a 15+ character passphrase at the rate of 100
attempts per hour the user whose account they were attacking will have long
since retired. Not to mention the fact that the admins would pretty quickly
notice that many failed login attempts in the log.

A pass phrase like: "My 2 dogs are cute!" is easy to remember, doesn't need
to be written down, is nearly impossible for a random stranger to guess and
is 19 characters long with spaces, numbers, mixed case and punctuation.
Good luck breaking that at 100 tries per hour.


--
-Ben-
Ben M. Schorr, MVP
Roland Schorr & Tower
http://www.rolandschorr.com
http://www.officeforlawyers.com/outlook.htm


"Shurick" <Shurick@discussions.microsoft.com> wrote in message
news:F78DAC49-8A0E-4526-836D-8CB16A31BEB0@microsoft.com...
> Hello,
>
> Help me to solve this dilema. What scenario is more secure?
>
> 1. I apply policy to change their passwords every 2 months.
> 2. I apply policy that passwords are never expired.
>
> In first scenario half of users will store their passwords on stickers and
> that confuse me.
>
> Thank for any suggest!

 

[Mark Randall]

"Ben M. Schorr, MVP" <bens@bogusaddress.mvp> wrote in message
news:3851CEA8-1D67-4FD7-8AD3-DB9B178C92F3@microsoft.com...
> We also set the lockout policy so that an intruder could only brute force
> attempt about 100 passwords in an hour. By the time an intruder
> successfully brute forced a 15+ character passphrase at the rate of 100
> attempts per hour the user whose account they were attacking will have
> long since retired. Not to mention the fact that the admins would pretty
> quickly notice that many failed login attempts in the log.

Not to mention how many terabytes of bandwidth it would take to break
something 8+ chars.

--
Mark Randall
http://www.awportals.com

 

[Anteaus]

"Ben M. Schorr, MVP" wrote:

> I don't force password changes, generally. I prefer to force long pass
> phrases and let people select their own pass phrases.

That is a very sensible arrangement. The only issue is that not all
third-party programs will accept such long passphrases, or allow spaces in a
password. But, if all of your passworded software can comply, then it's a
good system.

 

[Alun Jones]

"Ben M. Schorr, MVP" <bens@bogusaddress.mvp> wrote in message
news:3851CEA8-1D67-4FD7-8AD3-DB9B178C92F3@microsoft.com...
>I don't force password changes, generally. I prefer to force long pass
>phrases and let people select their own pass phrases. That way they can
>select things that are easy for them to remember and because the pass
>phrases are long (15 characters+ generally) they are nearly impossible to
>brute-force.

One consideration to make is that the enforced password change isn't just
about fixing the problem of the brute-force guesser, but also that of the
password sharer.

Yes, I know, we all drill it into our people to never share passwords, and
in many places sharing a password is a firing offence. Yet people do it, and
the pragmatic security manager will take steps to deal with this - requiring
periodic password changes is a prudent measure to adopt against the
likelihood that you've recently fired someone who has the password of
another employee's account.

Another risk avoided by regular password changes is that of being unable to
cope with a password change. If you have a service, or a script, or anything
that needs to authenticate itself, and the password gets exposed, you will
need to change passwords on it in a hurry - are you going to be able to do
that without pulling down the house of cards if you haven't done it on a
regular basis?

Every 90 days or so would seem reasonable.

Alun.
~~~~

 

[Anteaus]

Yes, this is true.

The prevalence of password-sharing is a direct consequence of NT/XP's
_enforced_ user-profiling, and its effect on stand-in users.

On Win9x you could stand-in for another person using your own network
username and password, and the local machine's settings would remain as
before, programs would perform as expected, etc. Thus, there was never any
need to disclose your password to everyone who might have to stand-in for
you. Personally, I reckon that was a better arrangement, for what is supposed
to be a personal computer.

"Alun Jones" wrote:

> Yes, I know, we all drill it into our people to never share passwords, and
> in many places sharing a password is a firing offence. Yet people do it...