|> Date: Sat, 4 Jun 1994 12:36:33 -0400 (EDT)
|> From: [EMAIL PROTECTED]
|> Cc: [EMAIL PROTECTED]
|> References: <[EMAIL PROTECTED]>
|>
|>
|> [EMAIL PROTECTED] (Chris Cowan) writes:
|> > 1. The -notify flag for bos.
|> > I wish this was called for all state changes of a Bos instance (and it
|> > passed the new state as an argument!). Right now, it only reports an
|> > instance going down!!! Anyway it's very easy to send a trap/alert when the
|> You can do this yourself by either adding the notifier to a bos
|> instance, or by writing simple (shell script, even) wrappers for the
|> processes you want to watch.
Yes, I could put an extra instance in Bos, but that would only trigger
if I did a bos restart -all. If I shut something down and then bring
it back by instance, then I have to use your wrapper idea.
I guess the wrapper idea would work, but I still think my suggestion is
better. I have found that for systems management, things work best if the
application sends its own traps, rather than relying on a poll!
|> > 2. kpwvalid
|> >
|> > I wish this exit was performed at the server end, not the client end.
|> > Even though it has to be in the same directory as kpasswd, there's nothing
|> > to stop a clever user from circumventing the whole thing by
|> > copying kpasswd to the local file system and using a checker of his own
|> > choosing.
|> >
|> > I think it would be much more effective if the passwd was verified by
|> > kasserver before it updated the kas db!
|>
|> Yeah, I agree with you, at least partly. We had several constraints,
|> however:
|> 1. backward compatibility had to be maintained.
|> 2. admins could be not expected to _replace_ kpasswd with their own
|> custom version of kpasswd.
|>
|> Because of #1, old versions of kpasswd would continue to work, and
|> clever users could write their own versions of kpasswd using the
|> existing RPC.
|>
|> We did consider punting #1, or phasing it out over a couple of years.
|> Unfortunately, that would require sending the actual password over the
|> wire. Now, we would encrypt it of course, but the kaserver would
|> decrypt it and inspect it, which would provide an opportunity for an
|> unscrupulous admin (or a "cracked" kaserver) to record passwords.
Unscrupulous admins wouldn't be a concern in our case. We're pretty
tight fisted here (and about to go further!)
|> Somebody is probably thinking "but the key is all you need." That's
|> true for access to *this* cell, but to impersonate someone in another
|> cell you need their password. People frequently use the same password
|> in multiple cells -- it was that realization that drove us to use the
|> cell name in our string-to-key algorithm.
|>
|> So that sort of complicates things. Now let me rationalize a bit.
|>
Yeah, I see the problem.
The password is never passed in the clear and backwards compatibility could
be a problem.
Here's an idea, suppose kpwvalid was implemented as a separate RPC server.
kpasswd could be changed to attempt another call before requesting the
change. You could have an extra flag on kasserver to fork the extra
daemon.
(Either way, I'm hoping that the DCE/DFS people are at least looking at
what you've done so far!!)
|> Probably the most important factor in maintaining the security of an
|> AFS cell is the quality of the passwords chosen (especially those of
|> admins, of course.) Given that, what rational person would choose to
|> permit their ID to be compromised? So we decided to provide a tool to
|> assist rational people in choosing good passwords. (I'm going to get
|> some flames on this, but I am willing to debate further whether users
|> are truly rational. I will contend that they are almost always as
|> rational as admins.) The trouble is that "good" can mean a number of
Unfortunately, out of our community of 5000 users, there are some that don't
see the logic of the arguments you present above. As an admin I worry,
because I think some will attempt to circumvent the checker. (Either way,
the admins will be blamed). Their arguments are these:
1. A lot checkers force users to use something that may be difficult to
remember. The argument then goes that they will resort to writing
them down on notepads, blotters, etc! As a result, you end up with something
just as bad as bad password quality.
2. If I know the rules, then I can optimize a cracker for those rules.
(This is an impossible argument, I know. However, it will be used by
some as their rationale for not choosing good passwords!)
To make matters worse, the powers that be in IBM are insistent that have
mandatory pw quality checking!
|> > 3. The monitors (afsmon, scout, etc)
|> >
|> > I wish all of these had script exits when trigger conditions were met.
|> > (Analogous to the -notify option in #1). My reasoning is the same as it
|> > is for #1, as well.
|>
|> agreed.
|>
We have a hack to scout here in Austin, I'll check to see if I can send the
diffs!
