begin quoting John H. Robinson, IV as of Thu, Nov 29, 2007 at 02:59:33PM -0800: > Stewart Stremler wrote: > > This is because you're not defending against a stolen /etc/shadow file, > > but an accidental revalation of a password? > > If I know that an /etc/shadow file got stolen, all passwords are expired > immediately. I don't think anyone disagrees.
This is the best form of password expiration. When it happens, it happens *now*. > The threat I am most concerned with: a user uses the same password on > multiple systems. I can (theoretically) prevent a person from using the > same password on two systems that I control. I cannot, however, prevent > that person from re-using it elsewhere, such as New York Times. > > Therefore, I must treat all passwords as potentially exposed. Not > because I know they have been, but because I cannot prove they have not > been. Indeed. And that's my problem with password expirations. Force a user to replace passwords, and they're minimize their pain: they'll reuse passwords, or use the same password in a lot of places. >From my point of view, this *increases* exposure. > > > There is a tradeoff between security and usability. > > > > Um..... I really hate describing the tradeoff in those terms. > > Can you think of a better, more accurate way? Security/Convenience, perhaps. > > Remember, one of the goals of security is accessibility. If my security > > policies result in my being unable to access my resources, that's as > > good as a denial of service attack. > > Remember the joke about the Secure Windows NT system? Stripped of cdrom, > floppy drive, sealed in cement and burried in the bottom of a well. This > is certainly a secure system. It is also the epitome of an unusable one. > > The most useable one would let you access it and provide no impediments > such as usernames or passwords; much like the public terminals at the > library. No, I don't buy that either. A system that I can't trust isn't usable either. > Somewhere between those extremes is where the users and the admins need > to meet. Maybe couching it in such confrontational terms isn't such a good idea. [snip] > > > To use the car analogy, you want to drive your car down the road, the > > > sidewalk, through the parks and at any speed you want. No. There are > > > laws. > > > > Yah, but fitting an explosive charge to the engine to blow up the car if > > I fail to signal before a right-hand-turn doesn't aid me in getting done > > what I need to do. :) > > Granted. Do you think that expiring a password is analogous to the above > scenario? Heh. I was thinking about driving in the park. With password expiry, it would be more like having a cutoff-switch on the system if I don't change the oil every 3 months and/or 3,000 miles. 3 months and two days, the car won't start; 3017 miles, the car won't start... [snip] > > Yup. Find the tradeoff. What threats concern you? What threats don't? > > What sort of users do you have? > > > > Do you allow authorized_keys? Do you /require/ authorized_keys? > > These are all good questions, and something each site should keep in > mind when coming up with or reviewing password policies. Yup. > > > I'm saying that I don't know, I cannot control it, so I must guard > > > against it. One of my tools is password expiration. I will use that > > > tool, along with others, as appropriate. > > > > The problem with password expiration is that it causes more problems > > than it solves. IMNSHO, of course. > > What would you recommend to mitigate the inadvertent and unknown > password exposure? Monitoring. Keyfobs. OTP for remote logins. Depending on the users, noexec /home, /tmp/, /var, and /scratch. > > Rainbow dictionary attacks are neat! > > http://rainbowtables.shmoo.com/ > I have no idea how large those things are. > > http://www.freerainbowtables.com/en/download/ > These look incomplete. > > http://www.codinghorror.com/blog/archives/000949.html > has some numbers for the size of these rainbow tables (.6 GB to 64GB for > 14 character length passwords, using a saltfree NT hash). Since UNIX > tends to use crazy_insane salts (especially if you use MD5 hashes), the > rainbow table attack is not terribly useful. > > http://en.wikipedia.org/wiki/Rainbow_table Salts just increase the effective length of the password; consider the length of the password and the length of the salt together. 14 characters is only 64GB? And I have 700GB of disk near to hand, with Petabyte drive arrays in affordable reach? Like I said, they're neat! -- 15-character passwords are even harder to remember than 8-10 character ones. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
