Thanks for the piece of wisdom... Again, I'm following the rules of my employer and will forward this information for further evaluation. My intent is to hardened the core OS (RHEL5) and without creating a flame war.
On Mon, Mar 17, 2008 at 9:37 PM, John Summerfield < [EMAIL PROTECTED]> wrote: > Kennie Cruz wrote: > > List, > > > > Are they any recommended strategy or cook book for hardening a RHEL5 > Server > > box. I did the usual, limit access to tty's, eliminated unneeded > services > > and applications and password aging. Your help will be appreciated. > Thanks. > > password aging? > > It's long mystified me why people think this a good idea. If I'm the > kind of user who thoughtfully chooses a good password I can remember, > and I'm the kind of person who does not disclose it, why force me to > change it? > > If I'm the kind of person who discloses his password, how does changing > it regularly really help? > > I can choose a reasonable password with good prospects of remembering it > by combining words. How likely are you to guess "bluecucumber?" > > If you the administrator allow access to the securely-encrypted value of > my password, or you allow unlimited attempts to guess it, then you sir, > are an unmitigated twit. > > Now if I forget one password in ten (and I reckon that's a good rate of > remembering them), and you require me to change the password each month, > then the likelihood is that I will forget at least one password in any > given year. > > > Google this: > > http://www.google.com/search?num=100&hl=en&c2coff=1&safe=active&client=mozilla&rls=org.mozilla%3Aen-US%3Aunofficial&q=%22best+practice%22+password+Spafford+site%3Aedu&btnG=Search > and be sure to read this wwhich is much quoted elsewhere > http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ > > > > "In summary, forcing periodic password changes given today's resources > is unlikely to significantly reduce the overall threat — unless the > password is immediately changed after each use. " > http://h20325.www2.hp.com/blogs/reed/archive/2006/04/23/948.html > > > http://www.wnj.com/privacy_4-24-2006/ > The UK study also found that the more IDs and passwords an employee had > to remember, "the more likely the business is to have had unauthorized > access" to its data. The study found that on average, users must > remember three different user IDs and passwords. "Password overload > hurts security, survey finds," > > http://news.com.com/Password+overload+hurts+security%2C+survey+finds/2100-7355_3-6064668.html?tag=html.alert > > > http://blogs.technet.com/steriley/archive/2006/04/30/Security-myths-and-passwords.aspx > Comments > > # Dan Halford said on April 30, 2006 6:17 PM: > I have always felt that by requiring regular password changes, site > administrators do very little to improve the security of the site. They > simply ensure that users pick a succession of equally insecure passwords > (xxx1, xxx2, xxx3, etc). > > Password frequency is never a substitute for good operational > security and user training. It doesn't take much to teach a user the > difference between a bad password and a good password, and it's equally > simple to convince a user why they should go to the trouble of picking a > good one. > > > As for me, I think that password complexity rules are insane. Here is a > password I no longer use: %09bjBWvb How many people can remember such a > password? I don't, I just store them all in a file and then keep other > out. > > I think that if you prevent, say, more than three consecutive failures > in a short time (then lock the account for an hour or so[1]), eight in a > longer period (and then lock the account until manually unlocked) and > keep an eye on accounts with high failure rates, then you don't have > much problem with password guessing. > > Finger readers, smartcards and so on might be helpful. So is an > electronic key to the relevant areas. > > [1] and require the user to acknowledge that there have been failures, > and inform them when and where they occurred. > > > > -- > > 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 > -- Kennie J. Cruz Gutierrez [EMAIL PROTECTED]
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
