On Sun, Jul 18, 1999 at 05:34:49PM -0400, Pete Gonzalez wrote:
> Thanks for the quick reply. BTW, is this a "bug" or a "feature"?
> It seems kind of unusal to have a daily cronjob that uses the cleartext
> administrator's password. For example, the server could instead validate
> the client with a simple zero-knowledge authentication scheme such as
> the one described here:
>
> http://srp.stanford.edu/srp/doc.html
I don't see how that would get the password out of the daily cronjob.
This is from the protocol description:
User -> Host: U, A = g^a (identifies self, a = random number)
Host -> User: s, B = v + g^b, u (sends salt, b = random number,
u = t-bit random number)
User: x = H(s, p) (user enters password)
^^^^^^^^^^^^^^^^^^^^
However, it is interesting that the auth2.pw file wouldn't have to
contain xor-ed cleartext passwords anymore. We currently need them
because of the shared secret authentication/key exchange.
> Is the 25-hour rule inherited from AFS?
No, I believe that came from kerberos. In fact kerberized machines have
a srvtab file which is as far as I know used as some `unlimited and
unsecured token' for daemons. But I'm not completely sure how it is
used, maybe it is used by a daemon like a password to get new session
tokens.
You could mimic this by using the tokentool to create a token which is
valid for the next year or so, and from the cron start *)
clog -fromfile /etc/codatoken
Not that I recommend this, the current scheme with a cleartext password
in the cronjob obtains a new session key every day. And as soon as it is
known that a daemon password has been compromised it can be changed and
any `illegaly' obtained tokens can only be used for a maximum of 25
hours. Also a daemon shouldn't need to be given Coda administrator rights.
Jan
*) or "cat /etc/codapassword | clog -pipe ftp/web/mail", which does get
a new session key. This is just as insecure as putting the password
in the cronjob, but simplifies changing the password on a group of
hosts.
