On Tue, Mar 18, 2008 at 6:43 PM, John Summerfield <[EMAIL PROTECTED]> wrote: > 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. ... > > 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. > 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 > 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). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
