Unexpected Stash Crowd SSO Behaviour

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:

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

On the second computer:

  1. Open a Firefox instance (do not navigate to Stash, or any Crowd authenticated website).
  2. Open Firebug and go to the Cookies tab. Use Create Cookie to create the crowd.token_key you noted from the first computer.
  3. 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]

2 answers

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

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.

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

Suggest an answer

Log in or Join to answer
Community showcase
Piotr Plewa
Published Dec 27, 2017 in Bitbucket

Recipe: Deploying AWS Lambda functions with Bitbucket Pipelines

Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda&nbsp...

699 views 0 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot