Why couldn't someone generate a reverse lookup table for encoded passwords? While you may not have a list large enough to support every possible combo, you'd most likely catch a percentage. 34 bytes of scramble using 100 bytes of letters is 34^100. At a storage of 10bytes per crypt, that's only 1405696955498267491541705127961637555026742863683784726712507274522355585042 1375738353462126192822446216645285577331757179064570911224592286631478438133 760 bytes to store every possible combination. The same bucket that contained the first encrypted password probably has 100 to 1000 more in the same bucket.
Seems far easier to use a camera to watch folds type their password at Starbucks or at the no-tell motel. That or a packet sniffer. You can never underestimate the laziness/complacency of users. Bill Watson [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen John Smoogen Sent: Tuesday, March 18, 2008 11:34 AM To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list Subject: Re: [rhelv5-list] Hardening RHEL5 On Tue, Mar 18, 2008 at 6:04 AM, John Summerfield <[EMAIL PROTECTED]> wrote: > > Stephen John Smoogen wrote: > > 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. > > 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. > > > > > >> 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 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'. 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. > > 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. -- 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 _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
