Unexpected Stash Crowd SSO Behaviour

Question

I have been discussing this with the Crowd Support team; but would like to see if others observe the same behaviour (or if it is something I have misconfigured) and whether you consider it expected or a problem.

For this I am using two computers with Firefox and the Firebug add-on (to manipulate cookies).  Stash authenticates against Crowd and uses SSO.

Test Procedure

On the first computer:

* Log in to Stash and navigate to a page in your Stash instance.  Note down the URL for later.
* Open Firebug and go to the Cookies tab.  Note down the crowd.token_key.

On the second computer:

* Open a Firefox instance (do not navigate to Stash, or any Crowd authenticated website). 
* Open Firebug and go to the Cookies tab.  Use Create Cookie to create the crowd.token_key you noted from the first computer.
* Type the direct URL you noted from the first computer...

With my implementation you gain access to Stash on the second computer without having to enter any passwords.

[Sorry, I don't seem to be able to attach any example images to the question]

Mark Bewley · Answer

This has been confirmed as a bug and now has a Jira issue, https://jira.atlassian.com/browse/STASH-4797

Mark Bewley · Answer

Thank you for that explanation.  I believe this would be the expected behaviour if the "Require Consistent Client IP Address" option is turned off in the Crown Session Config options.

In my test they are separarte computers, with different IP addresses, on the LAN.

The Crowd debug logs show the IP address is being used as a validation factor.  When the second computer uses the duplicate session cookie there are 6 "The token keys don't match" messages then it generates a new token (so the second computer actually gets a new session cookie).

This doesn't happen with Jira; using the SSOSeraphAuthenticator.  You are quickly redirected to the log in page.

Ensuring Stash is secure is important to us as this gives access to source code and IP.

Caspar Krieger · Answer

This is normal and completely expected behaviour of logging in to most websites.

If you can provide the token (the cookie's value) which demonstrates that you have authenticated previously, you must be the same person. Being able to impersonate someone like that by stealing their session cookie is why TLS is so important; it helps prevent session hijacking.

You can add another layer of protection by recording certain validation factors which must be provided together with the token; the server then rejects the token as invalid if the validation factors provided when verifying the token do not match the validation factors provided when the token was created.

Crowd supports this too and off the top of my head (i.e. without checking the code) I believe Crowd will use the IP address of the request which created the session token as a validation factor by default. If SSO is enabled then Stash should be doing the same thing. Did you perform this test on 2 computers which appear to have the same ip address to Crowd/Stash by any chance (e.g. 2 pcs behind NAT, or 1 pc with 2 different browser instances)?

(I'm a Crowd developer.)