Re: Reasons and examples for security

From: Steve Riley [MSFT] (steriley_at_microsoft.com)
Date: 12/15/04 

Date: Wed, 15 Dec 2004 10:00:58 -0800

I hear this argument frequently but I'm not sure I believe it. All through
my professional life there have been instances of where I've had to change
behavior:

* moving from OS/2 to NT4 at the electric company I worked for (10,000
users, foom!)
* switching from ID/password to smartcard for VPN log on (at Microsoft)
* waiting the additional 30 seconds for SMS to do its thing when I log on

I could go on. The point is that in all organizations there are times when
you arrive at work the next morning there's been some change in your daily
procedure. Sure there's some grumbling but ultimately everyone gets used to
it. I seriously doubt people will quit their jobs because you've hacked AD
to enforce a minimum length of 20 characters. (And if someone does, were
they really worth keeping around anyway?)

This is how I'd implement such a policy:

1. Get buy-in from upper management. This can be easier than you imagine if
you spend a few moments quantifying the risk -- the potential loss -- of
your current password policy. How much will it cost to recover stolen data
or your reputation from a successful password attack? Or how much are you
spending now _per call_ each time someone calls the helpdesk to have their
short but complex password reset because they forgot the thing?

2. Embark upon an education program. Help people understand the value of
their passwords and the value of information to the organization. Explain
the risks you've got now. Market the hell out of how much better simple long
phrases are. Maybe even throw a little party during lunch or something. Get
an exec to be a part of your messaging campaign.

3. Publicly annouce the switch-over date so that there is no surprise. This
is really what people resist -- _unexpected_ change. Take away the
uncertainty.

4. Implement your change on the announced date.

Steve Riley
steriley@microsoft.com

"Roger Abell" <mvpNOSpam@asu.edu> wrote in message
news:eVFaT9q4EHA.1260@TK2MSFTNGP12.phx.gbl...
> Hi Steve,
>
> Agreed, and excellent point.
>
> The bottom-line however is that there is extreme resistance to
> setting pwd length large enough to literally force passphrase use.
> Hence the "so-called" complexity setting still has a place when
> the length is set sufficiently low that some might use "myfullname"
> or other, particularly dictionary susceptible choices.
>
> IOW it is more simple to get the org to buy into increasing length
> slightly and beginning user passphrase education than it is to do
> something like increasing length drammatically (even with dropping
> of complexity). What they fail to appreciate is what you rightly
> point out - a larger length setting but without complexity requirements
> is more simple to remember (and more effective considering those
> that will not adopt passphrase use if length is less but with complexity).
>
> --
> Roger Abell
>
> "Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
> news:ezqRo8i4EHA.3908@TK2MSFTNGP12.phx.gbl...
>> > Teach them to use passphrases "The 4 BroWn CoWs jump!'
>>
>> Pass phrases do not need complexity. The benefits of passphrases are:
>>
>> * length -- defeating cracking programs
>> * easy to type -- defeating shoulder-surfing
>> * simple to remember -- defeating sticky-pads
>>
>> A phrase like "the four brown cows jump" will take on the order of
> hundreds
>> of centuries to crack and is much quicker to type and easier to remember
>> than "The 4 BroWn CoWs jump!" with all the latter's non-standard
>> capitalization and punctuation.
>>
>> If we're going to try to effect wholesale change here and get people to
>> agree that long passphrases are the future, adding complexity will create
>> resistance. Why do that when it's unnecessary, security-wise?
>>
>> Steve Riley
>> steriley@microsoft.com
>>
>>
>>
>> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
>> news:OWwkyyY4EHA.3472@TK2MSFTNGP09.phx.gbl...
>> > Changing passwords on a timed schedule intends to do
>> > a couple of things (at least): make the password different
>> > before a process that is trying to crack it has had sufficient
>> > time (statistically) to have done so; to limit unauthorized
>> > accesses that may be happening due to "handed out" and/or
>> > otherwise compromised passwords by invalidating them.
>> >
>> > For the first of these to be meaningful now-a-days, the
>> > balance between password size (and strength) and the
>> > change interval needs to be set reasonably - but of these
>> > the two factors which Windows can leverage without any
>> > third-party software is password aging and length.
>> >
>> > Teach them to use passphrases "The 4 BroWn CoWs jump!'
>> > and set the length high, IMO not less that a dozen. Set the
>> > aging so they cannot reuse passwords, and the frequency to
>> > what the users will bear, maybe 60 days if you can.
>> >
>> > Windows is not Unix. An account is in very many groups.
>> > These groups are used to control access to data which may
>> > be of different degrees of import/sensitivity and shared
>> > by different sets of people. This is something that is not
>> > at first well appreciated by folks coming from Unix, where
>> > an account being compromised imperils the data of that
>> > account and of its group.
>> >
>> > --
>> > Roger Abell
>> > Microsoft MVP (Windows Security)
>> > MCSE (W2k3,W2k,Nt4) MCDBA
>> > "roshak31" <Roshak31@news.postalias> wrote in message
>> > news:71471564-180B-43B4-944A-B8FA41EB7E34@microsoft.com...
>> >> I am looking for examples to support my case for tighter security. I
>> >> am
>> >> looking in the area of having to renew passwords at set time period
> which
>> > is
>> >> not currently being done. I am also looking to find any supporting
>> > arguments
>> >> for not having all home folders of everyone on the network available
>> >> to
>> >> everyone else on the network.
>> >>
>> >> Any stories and or arguments that would help my case for stronger
>> >> security
>> >> would be appreciated.
>> >>
>> >> Thanks,
>> >
>> >
>>
>>
>
>

Relevant Pages

  • Re: Reasons and examples for security
    ... setting pwd length large enough to literally force passphrase use. ... of complexity). ... >> otherwise compromised passwords by invalidating them. ... >>> I am looking for examples to support my case for tighter security. ...
    (microsoft.public.security)
  • Re: truecrypt keyfile complexity question
    ... to achieve the complexity equivalent to a diceware passphrase? ... the same selection of diceware files for a truecrypt keyfile passphrase ...
    (sci.crypt)