Password Policies

I wish to stir up the password policy debate. I have looked around for best practices for password policies. I see more and more articles saying that you should increase the complexity of the passwords and make it so that users don’t change their passwords as often. I understand and see the logic purported by some that a strong password should not need to be changed as often. Some of the logic goes that people who one, hate passwords and two, have to change them often will come up with a scheme that fits the policy but is easily predictable. For instance we have found out that a large percentage use month and year as their password.

What I don’t see in the debate is the user expectation that they can connect with any device from any location and access corporate data and how that should effect password complexity and the change of password frequency.

Let me give you a for instance. For us, users without remote access have the same complexity requirements but only change their password every 120 days. Users with remote access change passwords every 40 days.

The logic in this is that if they attempt access from a compromised platform, say a computer in a hotel’s business center that has had a key logger placed on it (or even a home computer where the kids have done who knows what and been who knows where on the Internet), the password that they use is then compromised but there is a limited time the password is good for. Our VPN remote access does check for anti-virus being up to date, a scan run in the last 30 days and so forth, but it checks those things only after the credentials are presented, thus the password is compromised. Remote access for things like Novell Filr, GroupWise web access do not have the “security” checks the VPN does and make reinforce the logic listed above.

What is the prevailing thoughts in your organization regarding passwords in general and has any thought been put into how remote access effects this policy?
  • DanW-MHTN;2351693 wrote:
    I wish to stir up the password policy debate. I have looked around for best practices for password policies. I see more and more articles saying that you should increase the complexity of the passwords and make it so that users don’t change their passwords as often. I understand and see the logic purported by some that a strong password should not need to be changed as often. Some of the logic goes that people who one, hate passwords and two, have to change them often will come up with a scheme that fits the policy but is easily predictable. For instance we have found out that a large percentage use month and year as their password.

    What I don’t see in the debate is the user expectation that they can connect with any device from any location and access corporate data and how that should effect password complexity and the change of password frequency.

    Let me give you a for instance. For us, users without remote access have the same complexity requirements but only change their password every 120 days. Users with remote access change passwords every 40 days.

    The logic in this is that if they attempt access from a compromised platform, say a computer in a hotel’s business center that has had a key logger placed on it (or even a home computer where the kids have done who knows what and been who knows where on the Internet), the password that they use is then compromised but there is a limited time the password is good for. Our VPN remote access does check for anti-virus being up to date, a scan run in the last 30 days and so forth, but it checks those things only after the credentials are presented, thus the password is compromised. Remote access for things like Novell Filr, GroupWise web access do not have the “security” checks the VPN does and make reinforce the logic listed above.

    What is the prevailing thoughts in your organization regarding passwords in general and has any thought been put into how remote access effects this policy?


    Probably better asked in the "Chat" forums.

    OES utilizes the NMAS/eDirectory for Password Policies and it's fairly customizable. Each organization has different needs. 2-factor authentication may help, but mobile device platforms may complicate things.

    --Kevin
  • On Thu, 02 Apr 2015 17:06:01 0000, DanW-MHTN wrote:

    > I wish to stir up the password policy debate.


    Simple version: all password policies inhale strongly. The only thing you
    can really do is try to pick one that inhales less strongly than the
    alternatives.


    > I have looked around for
    > best practices for password policies. I see more and more articles
    > saying that you should increase the complexity of the passwords and make
    > it so that users donÂ’t change their passwords as often.


    Most of these seem to be regurgitating the same thing as all of the
    others, mostly based on the Microsoft "3 of 4" rules. I've yet to see
    anything that proves any of the claims, or even really attempts to.


    > I understand
    > and see the logic purported by some that a strong password should not
    > need to be changed as often. Some of the logic goes that people who
    > one, hate passwords and two, have to change them often will come up with
    > a scheme that fits the policy but is easily predictable. For instance we
    > have found out that a large percentage use month and year as their
    > password.


    Yep. No matter how complicated you make it, your users will find a way to
    simplify it down to something that doesn't annoy them too badly.


    > What I donÂ’t see in the debate is the user expectation that they can
    > connect with any device from any location and access corporate data and
    > how that should effect password complexity and the change of password
    > frequency.


    The real discussion here is about risk vs. benefits. Is there a benefit
    to being able to access your corporate data from anywhere? Yes. Is there
    a risk? Yes. Now, is it worth the risk? Can you reduce the risk in a
    useful way? Is what you're doing _actually_ reducing the risk, or are
    your users working around your restrictions?


    > Let me give you a for instance. For us, users without remote access
    > have the same complexity requirements but only change their password
    > every 120 days. Users with remote access change passwords every 40
    > days.
    >
    > The logic in this is that if they attempt access from a compromised
    > platform, say a computer in a hotelÂ’s business center that has had a key
    > logger placed on it (or even a home computer where the kids have done
    > who knows what and been who knows where on the Internet), the password
    > that they use is then compromised but there is a limited time the
    > password is good for.


    40 days is plenty of time to take your captured password and exploit it.
    120 days vs. 40 days isn't really much of a useful difference when
    exploits can be automated and could potentially happen in seconds.


    > What is the prevailing thoughts in your organization regarding passwords
    > in general and has any thought been put into how remote access effects
    > this policy?


    I think what we're seeing is a shift away from the idea of "remote"
    access. There is no "remote". It's always on, always accessible, all the
    time. Multifactor may help with this, or it may not. In the end, you're
    going to have to trust (prove) that Bob is who he says he is. Once that's
    complete, Bob gets access to whatever Bob is supposed to have. If you
    need to only allow access to Bob's stuff when Bob is sitting in his
    office, you're not going to do that with passwords.


    --
    --------------------------------------------------------------------------
    David Gersic dgersic_@_niu.edu
    Knowledge Partner http://forums.netiq.com

    Please post questions in the forums. No support provided via email.
    If you find this post helpful, please click on the star below.
  • Sorry, but that isn't much of an answer. I understand the basics of what Novell does for authentication, I have been administering Novell products since 1994.

    The question being asked of me and in turn here has to do with "password age" and what best practices are and what others are doing? Does that clarify my question?
  • If I'm reading this correctly "40 days is plenty of time to take your captured password and exploit it. 120 days vs. 40 days isn't really much of a useful difference when exploits can be automated and could potentially happen in seconds." It does not matter what the "password age" in a policy is, if a password is compromised, you are hosed and limiting the time the password is good for will not limit damage? If that logic is followed through, passwords should change each time a person logs in which is not a possibility in my environment nor would it be tolerated.

    The battle I am fighting is one where the powers that be feel that 40 days is too short and we should go to 180 days or possibly never expiring a password. From what you are saying it makes no difference, make the users happy and move on.
  • DanW-MHTN;2351799 wrote:
    If I'm reading this correctly "40 days is plenty of time to take your captured password and exploit it. 120 days vs. 40 days isn't really much of a useful difference when exploits can be automated and could potentially happen in seconds." It does not matter what the "password age" in a policy is, if a password is compromised, you are hosed and limiting the time the password is good for will not limit damage? If that logic is followed through, passwords should change each time a person logs in which is not a possibility in my environment nor would it be tolerated.

    The battle I am fighting is one where the powers that be feel that 40 days is too short and we should go to 180 days or possibly never expiring a password. From what you are saying it makes no difference, make the users happy and move on.


    Users are never happy, LOL!

    Around where I work, the most common interval is either 90 or 120 days to change passwords.
    Complexity rules vary (MS is a bit funky in that regard in that it's 3 of 4, you cannot actually specify WHICH 3 you want, but eDir/NMAS can if you just pick 3 and force it on your users).

    Wait until you get into intruder lockout intervals and password-protected screensaver or other timeouts.

    "What? You mean I can't have a web app with an 8 hour timeout?"

    ha!
  • DanW-MHTN;2351798 wrote:
    Sorry, but that isn't much of an answer. I understand the basics of what Novell does for authentication, I have been administering Novell products since 1994.

    The question being asked of me and in turn here has to do with "password age" and what best practices are and what others are doing? Does that clarify my question?


    That's why I suggested the "chat" forum. This is more of a technical Q and A forum (ie: something's not working, it's broke, how do I do something, etc.). You're liable to get more debate/answers in the chat area, IMO if you ask as this forums is probably only looked at by people specifically for OES not password stuff in general.

    --Kevin
  • On Fri, 03 Apr 2015 19:56:02 0000, DanW-MHTN wrote:

    > If I'm reading this correctly "40 days is plenty of time to take your
    > captured password and exploit it. 120 days vs. 40 days isn't really
    > much of a useful difference when exploits can be automated and could
    > potentially happen in seconds." It does not matter what the "password
    > age" in a policy is, if a password is compromised, you are hosed and
    > limiting the time the password is good for will not limit damage?


    Essentially, yes, that's what I'm saying. Limiting the time that
    compromised credentials can be used does reduce your exposure, somewhat,
    but you've still got a 40 day window.

    Role playing as the bad guy for a minute...

    Give me your CFO's credentials and 40 days. Give me your CFOs credentials
    and 120 days. There's not much difference. Anything I can't get to in 40
    days isn't likely to be something I'm going to spend an additional 80
    days on.


    > If
    > that logic is followed through, passwords should change each time a
    > person logs in which is not a possibility in my environment nor would it
    > be tolerated.


    Yes. See also multi-factor authentication, one-time-use passwords (or
    tokens or magic keys or whatever else you want to call them), biometrics.
    That's why MFA is all the rage these days, because things like PCI
    compliance are *requiring* MFA because they see the need to have
    something that can't be easily compromised, stored, and re-used over and
    over again for weeks or months.


    > The battle I am fighting is one where the powers that be feel that 40
    > days is too short and we should go to 180 days or possibly never
    > expiring a password. From what you are saying it makes no difference,
    > make the users happy and move on.


    Essentially, yes. I don't think there's much difference in reality
    between 40 days and 180 days. Your bigger problem, at least if you're
    like here, is that phishing attacks work, and are immediately exploited.
    Training your users, including the CFO, not to be phished will do much
    more to increase your security than arguing over how many days valid
    passwords are good for. Teaching your users to pick good passwords will
    be more effective than encouraging them to change from "Secret1" to
    "Secret2" to "Secret3" as their 40 day expirations come up. Start looking
    at MFA if you need more security than passwords (technical need,
    financial compliance need). Work on creating a culture of good security
    practices, so that people understand what you're trying to do and why
    you're trying to do it.


    --
    --------------------------------------------------------------------------
    David Gersic dgersic_@_niu.edu
    Knowledge Partner http://forums.microfocus.com

    Please post questions in the forums. No support provided via email.
    If you find this post helpful, please click on the star below.
  • "Give me your CFO's credentials and 40 days. Give me your CFOs credentials
    and 120 days. There's not much difference. Anything I can't get to in 40
    days isn't likely to be something I'm going to spend an additional 80
    days on."

    That is saying that the password is compromised the day it as changed.

    If day the password is compromised 38 days after being changed, then the bad guy has 2 days or 82 days. It is not a good thing no matter how you look at it, but I'd rather have the compromised password good for less time than more.

    From what I am reading, if you want security, passwords are not how to achieve it. Yet if you have no budget to implement a second factor. . . it is all you have.
  • On Mon, 20 Apr 2015 15:46:02 0000, DanW-MHTN wrote:

    > "Give me your CFO's credentials and 40 days. Give me your CFOs
    > credentials
    > and 120 days. There's not much difference. Anything I can't get to in 40
    > days isn't likely to be something I'm going to spend an additional 80
    > days on."
    >
    > That is saying that the password is compromised the day it as changed.


    Correct. On average, you'd have to assume around 1/2 your password
    expiration time, so 20 days vs. 60 days, but my point remains the same.


    > If day the password is compromised 38 days after being changed, then the
    > bad guy has 2 days or 82 days. It is not a good thing no matter how you
    > look at it, but I'd rather have the compromised password good for less
    > time than more.


    Agreed.


    > From what I am reading, if you want security, passwords are not how to
    > achieve it. Yet if you have no budget to implement a second factor. . .
    > it is all you have.


    Passwords are one layer of defense. They're important, but they're not
    the _only_ layer. MFA is another layer. Yes, it costs money, but so do
    data breaches. Training is another layer, which can be relatively
    inexpensive, and extremely effective. Building a culture where social
    engineering attacks don't work isn't easy, but isn't necessarily
    expensive to do.

    I'm not saying that passwords don't matter, or that expiration periods
    don't matter. I'm just saying that it's only one piece of the puzzle. If
    you're getting resistance already, you're fighting your user base, which
    isn't going to make them amenable to training or culture building. Push
    too hard on any one thing, and you lose their cooperation. Lose their
    cooperation and they don't see a reason not to use "SooperSecret$1" and
    "SooperSecret$2" and on and on as passwords, since they meet your (in
    their mind, unreasonable) policy and stop thinking about the goals that
    policy was trying to reach.


    --
    --------------------------------------------------------------------------
    David Gersic dgersic_@_niu.edu
    Knowledge Partner http://forums.microfocus.com

    Please post questions in the forums. No support provided via email.
    If you find this post helpful, please click on the star below.