Again, - thanks for a very elaborate answer.
On 2012-09-04 18:45, Russ Allbery wrote:
Unless that cookie is authenticated, it means that logout doesn't actually
log you out in the presence of an attacker, since the attacker will just
set that cookie and then can use all the existing session cookies, yes?
Sure. The cookie needs to be authenticated.
And I'm not clear on how to authenticate that cookie within the WebAuth
protocol. You would really need public key cryptography to authenticate a
global cookie, with the WebKDC publishing a public signing key.
Yes... that was my thought too. But to be honerst, I didn't think too
much about it except convincing myself that at least this could be done
with public key cryptography.
However, any solution involving domain cookies only works if all your
WebAuth-protected servers are within one domain, something that WebAuth
does not assume and which is not true of, for example, Stanford.
Sure... I realize that my thought are of mostly theoretical relevance
for WebAUTH, since there's a lot of constraints around specific
installations.
Now, that's not quite what you're talking about -- you're talking about a
cookie that represents an assertion about the login state without carrying
authentication data, so stealing that cookie isn't particularly
interesting. But the problems of cross-domain authentication mentioned
above still apply.
Exactly.
I was trying to find a way for global logout under the premise that
every application server shared the same higher level domain.
The idea would be that the WebLogin server would
store, in browser local storage, the list of sites to which the user
authenticated, and then when you hit the WebLogin logout page, it would
use Javascript to tickle a known logout URL for each one of those sites
inside the browser so that each site could clear its own cookies.
Yes.. thought about that too. Made the JavaScript guys scream :)
Thanks for taking the time to consider my thoughts,
Peter
