[Freeipa-devel] [PATCH 61] Cache authentication in session

[Simo Sorce]

On Wed, 2012-02-15 at 11:24 -0600, Endi Sukma Dewata wrote:
> On 2/15/2012 8:01 AM, Simo Sorce wrote:
> >> If someone already has a session then changes to another principal, will
> >> he get a new session and then reauthenticate against the login URL? Or
> >> will he use the same session but just reauthenticate?
> >
> > I guess it depends on what you mean by "changes to another principal".
> > If you mean a simple kdestroy/kinit, then the interface will not see the
> > change until the session expires. (Which is why I want a session
> > expiration much shorter for Negotiate auth).
> 
> Even if we make it shorter (e.g. 5 minutes) there's still a window where 
> the browser is still using the old session. Will this be OK since it's 
> not about somebody leaving the machine idle, but in this case someone 
> else is taking over the machine while there's an active session? Also, 
> both users might not be aware about the length of this window.

My preferred way would be to have it configurable, but I think 5 min.
would be a reasonable compromise.

> > However if the user presses the logout button in the UI his session will
> > be destroyed and so the next attempt will cause a new negotiation to
> > happen and the UI will change to use the new principal.
> 
> Right, this is not the concern.
> 
> >> What if he then changes back to the previous principal, will he reuse
> >> the old session? If so will he be required to authenticate again?
> >
> > What old session do you refer to ?
> > The previous session of the same user has been destroyed, the other user
> > session is still valid until it expires or the user presses log out, so
> > nothing changes there.
> 
> Assuming there is a way for the server to detect principal change 
> earlier than session expiration,

There is none without a Negotiate operation which we now do only when
the session expires (hence my request for short expiration times).

>  the server could either (a) reuse the 
> same session but with new credentials, or (b) it could create a new 
> session for the new user. In option (b) there's a possibility to keep 
> the old session (thus the question about reusing the old session), but I 
> don't think we want to do that.
> 
> If the assumption is wrong, the only possible option is (b), but in this 
> case the old session is no longer available.

Right, the old session is always destroyed.

> That's true if the above assumption is wrong. We're already planning to 
> execute a whoami operation after each authentication so the UI can 
> detect the change.

ok

> >> Would it be possible for someone from another machine to randomly guess
> >> a session ID and then take over an existing authenticated session?
> >
> > The session ID is currently a 48bit random number (we ask John to make
> > it a 128bit number). *Guessing* that number is going to be *very* though
> > (read technically impossible if the randomness is properly handled at
> > the creation of the session ID in the server.
> 
> Hey... many people have won the lottery :)

I know nobody, do you? :-)

> > However if somehow the sessionid is exposed than an attacker can hijack
> > the connection. The risk is extremely low, but it is another reason why
> > having a short expiration for Negotiate auth would be better, than
> > treating it the same as form based auth.
> 
> Agreed, although the form based auth is still exposed to the same 
> hijacking issue.

Yes form based auth is just a leap of faith, you base all your security
on the SSL connection, and there isn't much you can do beyond that.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York