Stephen John Smoogen wrote:
> On Tue, Mar 18, 2008 at 6:43 PM, John Summerfield
> <debian@(protected):
>> 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?
>>
>
> Business groups get to make these decisions.. not the system administrators.

That doesn't really answer the question, does it?

>
> ...
>
>> > 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.
>>
>>
>
> I have read the paper several times, and havetalked with Dr Spafford
> about this in the past. I agree that blindly using it as a policy for
> all cases is stupid. However, there are cases where it does make
> sense, and Dr Spafford does not say it never makes any sense. Plus the
> military change is 90 days not 30 days.

Whenever the change, consider this.

Assume your password is xxxxxx
Assume that I am trying to brute-force your password (but you don't know
this).
Assume you change your password. Two possibilities exist:
1. You change to a password I haven't tested yet.
Is this change useful?
2. You change to a password I have tested, and you do indeed escape (for
a time).

Further assume that knowing this, I'm actually trying to crack several
accounts.

How often do you need to change everyone's password to defend against me?
If I can go through the namespace for one 6-letter password in <90 days
then I can go through the namespace for four 6-letter passwords in the
same period, with an equal chance of success of no regime for change is
in place, and a better chance if one is.


>
>
>> 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.
> ....
>> 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
                  ^^^^^^^^^^^^^^^
That is a point you did not make, but which I assumed. My assets are low
value (well, maybe I'd exclude my banking details but that's more the
bank's problem), and the likely cost of implementing something better an
excessive premium for the insurance cover it provides.

>> 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!
>>
>
> The above paragraph has been what I have been trying to say but am
> either not saying it clearly.. or somehow you discount everything I
> say because I disagreed with you. Please notice he says "flexible
> period for change"... dependant on your threat model. And also notice
> his last sentence assumes that you have OS protection against overall
> compromise. Those caveats have to be put into your threat model. If
> you threat model says you have to change your passwords within X days
> and X is too short for reasonable usage (likeliness of forgetting or
> writing your password down etc) you need to look at two-factor
> authentication (also what I have been trying to say).
>
>
He also says "In summary, forcing periodic password changes given
today’s resources is unlikely to significantly reduce the overall
threat...."



--

Cheers
John

-- spambait
1aaaaaaa@(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
rhelv5-list@(protected)
https://www.redhat.com/mailman/listinfo/rhelv5-list