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@cw.net