danw-mhtn Trusted Contributor.
Trusted Contributor.
1586 views

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?
Labels (2)
0 Likes
9 Replies
Knowledge Partner
Knowledge Partner

Re: Password Policies

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
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Policies

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.
0 Likes
danw-mhtn Trusted Contributor.
Trusted Contributor.

Re: Password Policies

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?
0 Likes
danw-mhtn Trusted Contributor.
Trusted Contributor.

Re: Password Policies

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Password Policies

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!
0 Likes
Knowledge Partner
Knowledge Partner

Re: Password Policies

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Password Policies

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.
0 Likes
danw-mhtn Trusted Contributor.
Trusted Contributor.

Re: Password Policies

"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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Password Policies

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.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.