On Mon, 2006-05-01 at 00:33 +0200, Marcus Brinkmann wrote: > You seemed to have missed a whole thread a couple of weeks ago.
This is probably true. I was working toward a deadline, and things were very difficult. Much of the Hurd mail did not get read for two weeks. Sorry. > At Sun, 30 Apr 2006 18:13:07 -0400, > "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > 1. There are overwhelmingly compelling reasons to set policies against > > stupid passwords. > > It is a matter of judgement if such policies need to be administrator > or system enforced. Yes. And the experimental evidence in favor of the need for policy enforcement about choices of password is overwhelming. However, I agree (below) that your proposed mechanism seems like it should work. > > This is why cracklib exists -- one bad password > > endangers an entire system. > > If this is true, then it is a defect in the system. > > The fault is in using passwords. Passwords and humans don't mix well. I agree with both statements. However... Accepting that it is a defect in the system, it remains a defect that we do not, in principle, know how to fully address. We can mitigate it. We can make systems more robust. We can make the potential damage less severe. After all of these things are done, it remains true that we simply have no solution for guarding sufficiently against the threat of an attacker with authorized access. I agree that passwords don't work very well with humans. Given that this is true, I still do not anticipate that people will abandon them any time soon. And of course, if a user can "plug in" an authentication mechanism, most users will plug in a bad one. In single-user systems this may be acceptable. I *hope* that Hurd might work for multi-user scenarios as well. As a practical matter, I do not know how to get rid of passwords within the next decade, and I do not know how to fully defend a system with a malicious user who has successfully authenticated. I will say something stronger: in the entire field of computer security, both in research and in practice, *nobody* knows how to sufficiently defend this type of system. > > This implies that even if the user owns the > > password file, we wish to restrict the conditions under which that file > > can be written. Indeed, using a purely user-defined authentication > > methods are a bad idea because of this. > > Here is a way to do it in the case where the user provides the > password file, and the system reads it: > > The system checks the conditions for the password that is _entered at > the login prompt_, rather than the password in the file. > > It is then the user's responsibility (with adequate support, of > course) to set a password that complies to the conditions. Yes, I think (provisionally -- still thinking) that this would work. I also agree that it seems like a fundamentally better system structure for authentication. In addition to everything else, it appears to eliminate a single point of failure (the password database). Very nice! > > 2. I'm not sure how something like 'su fred' would be implemented in > > this style of system. > > You mean as sysadmin without entering a password? No way, unless the > user grants access to the sysadmin without a password (provided there > is a mechanism to do so). Umm. No. I meant *with* the password. The part I am confused about is how 'su', which is spawned by me (therefore my child) gains read access to all of those password files (which is equivalent to read access on the password database). I suspect your answer may be that 'su' is not spawned by me, and that I have consistently failed to see this. If this is the answer, could you confirm? > > 3. What happens when the user accidentally deletes their password file? > > The user can not login anymore. Which is a good reason for not making > it a normal file in the first place (among other reasons not to make > it a normal file), but to have a dedicated service (which can still > run in the user's space). It occurs to me that this may not be what will happen. The password "file" is a standalone object with two bindings: one in the user directory and the other held by the login agent. If the user simply unbinds their capability, then the situation is that they can still log in but they can no longer change their password -- this is true because the login agent has not lost *it's* capability. This may still be the right thing, but it is decidedly weird! shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
