Database development plans

> At 15:08 -0800 29/1/02, David Kessens wrote:
> >Larry,
> >
> >On Tue, Jan 29, 2002 at 05:31:30PM -0500, Larry J. Blunk wrote:
> >>
> >>     As an alternative to deprecating MAIL-FROM, have you considered sendin
>g
> >>  a response to updates with a random cookie in it and requiring a 
> >>confirmation
> >>  message with the cookie?
> >
> >I like this suggestion.
> 
> 
> I think this is both complicated (for the user) and messy (for the 
> server) while not addressing the real issue. MAIL-FROM authentication 
> is just "no authentication", no matter how you look at it. Cookies 
> are really easy to intercept and with rate of updates a server like 
> the RIPE whois server has, keeping track of thousands of cookies 
> doesn't seem to see a reasonable solution if you take into account 
> the additional protection it offers. Also remember that people with 
> automatic scripts to handle their objects would need to adopt them to 
> the new model.


   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.


> 
> >
> >>     In regards to the MD5 fingerprint, would this be a straight MD5 hash, 
>or
> >>  something like the FreeBSD MD5-based password hash (which I believe suppo
>rts
> >>  passwords longer than 8 chars)?   Also, would the hash continue to 
> >>be openly published?
> >>  It would seem you would still have to deal with potential 
> >>dictionary attacks.
> >>  I understand the Perl-based RIPE server would use a "*" in place of
> >>  the actual crypt-pw and I've been considering adding support for 
> >>this in IRRd.
> >
> >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 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)
> 

   Having a hash/signature generator that checks for password goodness would
definitely be a big help.  In addition to a minimum of 8 characters,
I'd also suggest mandating some number of non-alphanumeric characters.


  Regards,
    Larry