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

[Tero Kivinen <[e-mail]>]

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

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


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

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

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.
-- 
[e-mail]

_______________________________________________
Tools-team mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tools-team