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