CoSign: Collaborative Single Sign-On  
AnnouncementsDiscussion
 

cosign-discuss at umich.edu
general discussion of cosign development and deployment
 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cosign Loop Breaking



On Thu, 3 Jun 2004, johanna bromberg craig wrote:

> There are a few misconfigurations that can cause a loop where a service
> will set a cookie, redirect back to the central cosign server, which
> will try and register the cookie, succeed, redirect back, where the
> "check" will fail, set a new cookie, redirect, re-register, etc. This
> will go on until the browser detects "too many redirects" ( this
> threshold varies by browser ) at which point a very unhelpful message
> will be thrown by the browser and the user is "stranded."
>
> I propose that we add some code to the cgi that keeps track of the
> number of REGISTERs in a given time period.  Our current idea is to
> tack on a time stamp and a count to the end of the login (cosign=)
> cookie, so we'd have:
>
> cosign=[random_bits_here]/[time in seconds]/[number of registers since
> that time]
>
> If a give login cookie exceeds X registers in N seconds, the cgi can
> throw a proper error screen giving the user some *actual* information.
> :) The current defaults I'm thinking of are 10 registers in 30 seconds.
> This is fairly arbitrary, and just where I'm starting?

I've thought about this for a while.  The solution seems like it
will work, and I can't think of problems that it would cause.  I
can't think of any advantage that a person could obtain by
deliberately falsifying the time or number of registers in their
cookie that they couldn't obtain currently simply by making up
their own cookies themselves from scratch.

I'm less than 100% comfortable with this solution, though, because
I don't know that it's the best solution to the problem; you just
say "there are a few misconfigurations that can cause a loop".
What are these misconfigurations?  I'd like the chance to explore
them and see if someone on the mailing list can come up with a way
to ensure that the misconfigurations never occur as a preferable
option to making the cookie more complicated and adding extra
functionality and special-case logic to the "core" part of the
cosignd code.  It may be that the solution proposed is the best
one; my point though is I don't know that because it's not clear
to me what sorts of misconfigurations are causing the problem.

I'm not saying "don't implement the proposed solution", I'm just
sharing my thoughts in general.

                Mark Montague
                LS&A Information Technology
                markmont@xxxxxxxxx



 
Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010