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