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 sending
>>  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.

>
>>     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 supports
>>  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)

Joao


>I hope this helps,
>
>David K.
>---


--