Stephen John Smoogen wrote:
For my scale of system, network bandwidth is a limiting factor,
especially as I limit sensitive network connexions (for us it's only
ssh) to five per hour from most of the world.
Then you would need to make a password changing policy to meet that
scale. Which could be 30 years. However in the case where you have
1000's of connection points, and probably have legacy software
(*cough* Oracle *cough*) that default to 7 or 8 letter passwords with
10's of thousands of users... your threat model changes.
And monitoring failures doesn't help? Why would you use the same (weak)
credentials for access to Oracle and to a shell account?
>
>
>> If I'm the kind of person who discloses his password, how does changing
>> it regularly really help?
>>
>
> Actually the case you are 'protecting' is where you haven't given out
> your password, but your hash has been found (say from a compromised
> computer or network service).
From my experience when they're in they're in.
Yes, the issue is that when they are in, can they get in again after
you find them. I read at one point that most system compromises are
not found for ~30 days... which gives the bad guys a 30 day window to
find other ways to get in. The easiest way is to make sure you come
back in looking like a legitimate user.. so in the threat model, you
have to consider that somewhere in your vast network, you have systems
that have at least 30 days to go through password hashes. Would a
brute force get the password in that time?
Again most of these rules are meant for enterprise, university, or
Er, I referred to a paper by Professor Eugene Spafford, writing from a
university perspective. Since he's cited here
http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2196.html and many other
places, I have to assume his credentials are better than mine. I didn't
find anyone say it's a lot of hogwash.
military sites where the number of systems you are in charge of are in
the 100's and the complete community is in the low millions. So the
rules for password changing are usually set up on the idea that you
have bad guys inside your network and outside, and they are going to
have access to stuff that is 'secret'... and that you have limitations
set aside from legacy software that requires you to put limits on your
'strength'.
"something you have" + "something you know."
You need a card and you need to know a passphrase.
So does changing your password every 90 days make sense for a small
business? Probably not. Does it make sense for a low number of targets
network (few users, few systems, few services, few insider threats)?
Probably not. Does it make sense in a large scale government
environment where you have millions of users,systems, services, and
insider threats.. yes.
With those numbers, a password isn't enough. If I have a stack of other
people's ATM cards, there's a pretty good chance one or more of them has
the PIN 1212.
> factor, OTP, brain implants, etc)
If I had high-value assets, my web server would not have any more access
to them than it needs. Nor would there be much access to the webserver
outside of http/https.
Regardless of what _I_ think, the Professor seems to have good
credentials in the area, and some empirical evidence supports it.
In most cases, security literature comes down to the old 12 rabbis,
144 different valid defendable opinions. It all depends on what your
initial conditions are and what point of view you are taking. Unless
you can put a definitive mathematical case that covers all scenarios,
then there are going to be variances of what is important per
environment.
I personally don't think that changing the password every 90 days is
important in every environment. Nor does changing the password
increase security in every threat model. However, in certain ones it
does, and those I do change it and also look for ways that I could
switch to 2 factor or one time passwords.
If you have a community of 1,000,000 passwords, you will certainly make
mistakes handling forgotten passwords. Compelling people to change
passwords regularly will make the problem of forgotten passwords worse,
not better.
Here is a direct quote from the professor's paper, I recommend you read
the whole thing. It's been there almost two years, I figure the people
at Purdue haven't refuted it yet.
http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/
So where did the “change passwords once a month” dictum come from? Back
in the days when people were using mainframes without networking, the
biggest uncontrolled authentication concern was cracking. Resources,
however, were limited. As best as I can find, some DoD contractors did
some back-of-the-envelope calculation about how long it would take to
run through all the possible passwords using their mainframe, and the
result was several months. So, they (somewhat reasonably) set a password
change period of 1 month as a means to defeat systematic cracking
attempts. This was then enshrined in policy, which got published, and
largely accepted by others over the years. As time went on, auditors
began to look for this and ended up building it into their “best
practice” that they expected. It also got written into several lists of
security recommendations.
This is DESPITE the fact that any reasonable analysis shows that a
monthly password change has little or no end impact on improving
security! It is a “best practice” based on experience 30 years ago with
non-networked mainframes in a DoD environment — hardly a match for
today’s systems, especially in academia!
The best approach is to determine where the threats are, and choose
defenses accordingly. Most important is to realize that all systems are
not the same! Some systems with very sensitive data should probably be
protected with two-factor authentication: tokens and/or biometrics.
Other systems/accounts, with low value, can still be protected by plain
passwords with a flexible period for change. Of course, that assumes
that the OS is strong enough to protect against overall compromise once
a low-privilege account is compromised….not always a good bet in today’s
operating environment!
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
