Re: [Tools-team] Agenda for the 14 June 2006 Teleconference

Hi Tero,

on 2006-06-15 11:09 Tero Kivinen said the following:
> Henrik Levkowetz writes:
>> > 1) That login manager really needs to require TLS protection, i.e
>> >    mandate that both the forms and the posts are always using TLS.
>> 
>> Yes.  But to do that, I need a proper cert for tools.ietf.org, which
>> I don't have.  I've been planning to talk with Ray about it for some
>> time, but no time...  I assume that this has to go through some
>> entity that can verify that we have a right to get a cert for
>> tools.ietf.org.   I also wonder if we need separate certs for
>> tools.ietf.org, www1.tools.ietf.org, www2.tools.ietf.org and
>> www3.tools.ietf.org...
> 
> As datatracker.ietf.org already has certificate, I assume someone
> knows how to get one...

Oh, I agree.  That won't be the problem, I hope.

> And yes, you probably need separate
> certificates for each host if you want to run separate tasks on each
> of them. If they are all identical i.e. referred always as
> tools.ietf.org, then one certificate would be enough, but I guess
> there will be some services that will be only on the
> www1.tools.ietf.org and not on the others. 

Right.

>> 
>> > 2) The URL for changing password should only work exactly once, not
>> >    for 24 hours. The problem with 24 hours is that if someone manages
>> >    to get the URL later from my mailbox or some other place he can
>> >    change my password after I changed it. If it works exactly once,
>> >    either I will get error that password has already been changed
>> >    using the URL (i.e. I know there was attacker who stole my URL) or
>> >    the attacker cannot change my password after I have successfully
>> >    changed it. Perhaps storing the used auth sha1sum to some directory
>> >    and checking that it cannot be there before continuing.
>> 
>> I agree, and this is already on my todo list, but I wanted to get the
>> base functionality out there first.  This can be accomplished without
>> changing what I have now, only putting in an additional check in the
>> script which verifies the hash.
> 
> I that can be quite easily added, by simply adding check after the
> auth data checking saying (using /bin/sh syntax as example)
> 
> if [ -f "$authfilesdir/$auth" ]
> then
> 	echo "Auth key already used"
> 	exit 1
> else
> 	# Auth key ok, mark it as used
> 	touch "$authfilesdir/$auth"
> fi

Sure, straightforward.

> 
> And then put cronscript that will remove all files from the
> $authfilesdir/$auth that are older than one day. 

Certainly.

>> Something else which you haven't mentioned but is also on my todo list
>> is rate limiting on requesting the mail with a new password URL, so
>> people can't anonymously annoy others with a stream of mails with
>> new password URLs.
> 
> If someone really starts sending thousands of those emails to some
> user then he must use quite a lot of his own bandwidth to send those
> requests, and after a while the tools.ietf.org machine will get
> slow as sending out those emails takes cpu resources...

The annoyance value of 50 emails from a source you don't want to block
is considerable - it's not so much a bandwidth issue as an annoyance
issue, and I'd rather prevent that.  Your proposed fix below makes it
possible to pursue the miscreant, but doesn't prevent the annoyance...

> What you do want to do is to add the information who sent the request
> i.e add things like:
> 
> ----------------------------------------------------------------------
> This request was made from 62.61.72.13:57673
> Browser Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.7.12) Gecko/20051028
> ----------------------------------------------------------------------
> 
> to the end of the email that is sent to the user when password is
> requested. That way user will at least know IP-address who is sending
> those requests, and can himself continue pursuing the attacker instead
> of asking you to check www-server logs...
> 
> I.e. add
> 
> echo "This request was made $ENV{'REMOTE_ADDR'}:$ENV{'REMOTE_PORT'}"
> echo "Browser $ENV{'HTTP_USER_AGENT'}"
> 
> to the end of email.

Yes, I may add something like this, it may be useful even if I add
rate limiting.

Regards,

	Henrik

Re: [Tools-team] Agenda for the 14 June 2006 Teleconference

Attachment: signature.asc