Database development plans

> 
>    I still feel that MAIL-FROM with cookie confirmation is 
> considerably
> better than "no authentication".   I don't see how a cookie is really
> any easier to intercept than a password or secret string sent in the
> clear.  It also doesn't suffer from potential dictionary cracking
> attacks.   While it is clear that user's will find it more complicated
> than the current MAIL-FROM, I could still envisage some
> preferring it over passwords/PGP-KEYs.
> 
>    I checked out majordomo's cookie confirmation code and found that
> the cookie generation uses a hash of a secret string, the user's
> email address, and the requested command.  Thus the server does not
> need to keep any cookie state.  One could include a timestamp in the
> cookie hash generation and confirmation message to help guard against
> replay's.
> 
>    Finally, I would imagine that those who are using automatic scripts
> would migrate to passwords or (preferably) PGP.
> 
> 

If the mail can be intercepted then a cookie confirmation
won't make a difference.
If the mail can be intercepted then a clear-text password scheme 
won't make a difference.

Only if the mail is secure then a cookie or password makes sense.

Also a cookie confirmation increases the chance to start a mail storm.

>> In my ISI/RPSL/6bone version of the perl server (=not the 
>> official RIPE version of the perl software) the crypt-pw is indeed not
shown upon
>> query or in the downloadable database files.

This is not a bad idea to shadow the crypted string 
(then MD5 is not really necessary ).
But I think the RIPE-DB server needs some structure changes to support this.

>> 
>> This is clearly a community decision. I would suggest that if MD5 is 
> > implemented as an additional method, strings bigger than 8 
> characters 
> > are a necessity (and it is really easy to do so with MD5). 
> The extra 
> > length makes it really difficult to have dictionary attacks if 
> > properly used (I mean you can use a file with the complete works of 
> > shakespeare when generating the MD5 hash)
> > 

If RIPE-DB are going to support different auth functions, 
why not using PAM to support any kind of PAM modules then ?

Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net