Re: Reasons and examples for security

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

  • Next message: r wisz: "Re: strange process" 
    Date: Thu, 16 Dec 2004 00:07:24 -0800

    > One thing that is totally unneeded but which would facilitate
    > is if there were some champion in MS to take up getting a
    > mod to the gina so that there were a password policy to
    > "Use passphrases" (with some details tbd relative to retraints
    > on length minimum and relationship with complexity policy).

    Some of us here are campaigning for exactly this. :) And also the ability to
    control by policy how long your minimum length is. Right now, the spinner
    control in the AD UI won't let you set a minimum greater than 14. If you do,
    it changes back to 14 before saving. This is for backward-compatibility
    reasons. We hope to enable longer required minimums in the future.

    Steve Riley
    steriley@microsoft.com

    "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
    news:edrm2qt4EHA.3368@TK2MSFTNGP10.phx.gbl...
    >I could not be in more agreement with those observations.
    >
    > In my experience, the sticking point is item 1) buy-in from
    > upper mgmt; which comes down to whether there is a
    > security officer and if so their relation (power/political/etc)
    > to those over IT and over customer/user support.
    >
    > One thing that is totally unneeded but which would facilitate
    > is if there were some champion in MS to take up getting a
    > mod to the gina so that there were a password policy to
    > "Use passphrases" (with some details tbd relative to retraints
    > on length minimum and relationship with complexity policy).
    >
    > Why? Simple. It is a beancounting leash sort of thing - "Hey,
    > if they facilitate it in the OS and advocate it then it must be
    > good, right?" - typical knee-jerk thinking . . . But I am surprised
    > at how such as this can be a factor, even after all of the
    > analyses (simplicity of cracking with their present pwd policy,
    > losses/liabilities/privacy legalities/costs, etc.) have not been
    > sufficient. I mean these folks believe a pwd of "Password1"
    > is good as it meets complexity and length > 8 before one
    > starts working on them !!
    >
    > --
    > Roger
    > "Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
    > news:%23fnMPAt4EHA.2192@TK2MSFTNGP14.phx.gbl...
    >>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,
    >>>> >
    >>>> >
    >>>>
    >>>>
    >>>
    >>>
    >>
    >>
    >
    >

  • Next message: r wisz: "Re: strange process"

    Relevant Pages

    • Re: 2003 Domain Password Policy with NT 4.0 Workstations
      ... The only way to exclude users from adhering to the domain password policy is ... > running Windows NT 4.0, so would the following scenario work? ... Modify the Default Domain Policy and remove the Account ...
      (microsoft.public.windows.server.active_directory)
    • Re: GPO configuration
      ... > There natively is no possible way to override/bypass domain password policy ... > GPO's for password/account policy. ... >> does an account/password policy applied at the domain level override OU ... I thought the lower GPO policies would overwrite the upper levels ...
      (microsoft.public.cert.exam.mcse)
    • Re: Different password policys?
      ... If you set Password Policy at the OU level, it will only affect the SAM ... database (ie local users) on any machines in that OU. ...
      (microsoft.public.win2000.security)
    • Re: Password policy
      ... Make sure that you configure domain password policy at the domain level ... Group Policy in the domain container then the Group Policy at the top of the ...
      (microsoft.public.windows.server.security)
    • Re: I am envious!
      ... You are right - I did fail to mention that I set the policy to send ... unencrypted password to facilitate my Samba interop. ...
      (microsoft.public.windowsxp.security_admin)