On Mon, Mar 17, 2008 at 7: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? >
The idea is to go with the standard rules of encryption. You assume the person who you are trying to prevent access has access to your hashed password. The time to change your password is then how long you need to keep your password is 'safe'. For a 6 letter password a single computer can go through the entire 'namespace' in <90 days, for an 8 letter password a couple of years. However, most 'bad-guys' usually have close to 100-1000 computers to do these hacks with (botnets are cheap if you want to get into a computer system). Compound this with the fact that most longer passwords use various mnemonics or patterns to be memorizable.. making it more likely you will 'guess' a password in a certain time frame. So since you know that your passwords are going to be guessed, and you know things like minimum length of a password and possibly 'strength' of that password, and the number of passwords you have in your system (for a small user ok 10.. for an enterprise 10k-1million).. you figure out what a length of time you want to make sure that what the attacker has is worthless (eg you have changed the hash and the password on them). For general systems this means probably changing the password 90 to 180 days for an 8-10 character password. If you believe your threat model is going to be people with access to even faster computers.. you change it so that no password is ever repeated using some sort of one-time-password method. > 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). > I can choose a reasonable password with good prospects of remembering it > by combining words. How likely are you to guess "bluecucumber?" > Actually for large cluster checks, you take a dictionary and put words together with 4 or 5 variations (change s to 5, s to $, etc).. split the dictionary and feed it to your 'cluster' of machines. It may seem expensive diskwise and cpu, but the hackers don't usually worry about that because they are using your neighbors computer (or the guy with RHL-7.2 and unpatched ssh) to store and calculate. The larger the number of passwords the hacker has gotten the more likely they will turn up because someone somewhere types in aaaaa1r0b!n to meet a standard.. actually they would most likely do a1qazR0bin! because most people put the number in the second spot, capitalize the word they are remembering and stick the special needed character at the end. And while a large enterprise should be using some sort of 2 factor authentication.. most of them don't. And when they do, the hackers will investigate the secondary places to get in like google searching for links between an enterprise and a university.. attack the university, get the passwords and piggy-back into the primary target. > 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. > And in the case where your webserver had an application that is compromised and someone gets to grab a set of ldap credentials.. for the home user and the small time user it doesn't make sense.. and it doesn't make sense in a threat model where you need to change it every 45 days or so. At that point, you need to invest in other methods (2 factor, OTP, brain implants, etc) -- 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
