Make the session cookie name configurable

[sagikazarmark]

Is your feature request related to a problem? Please describe.

Currently the session cookie name is hard coded to ory_kratos_session:

https:/ory/kratos/blob/master/session/manager_http.go#L43

I usually like to hide as much information about the underlying system as possible, especially if it's related to authn/authz for security reasons. (I don't want to tell an attacker what software I'm running.)

Describe the solution you'd like

It would be nice if I could override that session cookie name from configuration.

Describe alternatives you've considered

I guess the only alternative is to change the default to something like sessid that does not leak any information about the underlying infrastructure.

[aeneasr]

I think the way kratos works is quite unique so there will be a lot of vectors for discovering that someone is using kratos. Just by checking the redirect URL you can already figure out quite a lot in my opinion, I'm not sure if hiding the cookie name would actually change that?

[zepatrik]

I would also say that there are always ways to determine the software incl. version running if you want to. But making the cookie name configurable would not be a big deal anyway.

[sagikazarmark]

Right now the URL contains /.ory/kratos, but as far as I can tell, that can also be changed. A request ID is probably not that obvious.

Are there any other vectors that allow identifying the underlying software?

Most of the public responses seem to be redirects.

[zepatrik]

Basically all the paths and formats of payloads, as long as you don't intercept everything within your own backend and rewrite those paths.

[sagikazarmark]

Payloads shouldn't be a problem as long as I use server side rendering. What other paths exactly? /login /verify are neutral enough IMHO.

[zepatrik]

• /self-service/browser/flows/profile
• /self-service/browser/flows/requests/profile
• /self-service/browser/flows/profile/update
• /self-service/browser/flows/login/strategies/password
• /self-service/browser/flows/registration/strategies/password
• /self-service/browser/flows/registration/strategies/oidc
• /self-service/browser/flows/logout

just some I quickly found

Also having all those redirects and how they happen draws a pretty clear picture of the software used.

[aeneasr]

I think this is a nofix for us. If there's serious disagreement we can try and figure something out but honestly - the best protection is keeping up with releases!

[frederikhors]

I agree with @sagikazarmark.

Any information that can be hidden (or customized) must be possible.

I work with many companies that have these policy.

We should allow it, it costs us nothing.

I met the ory (and kratos) project a few days ago and I am already implementing it for some clients because I am very happy with it, but I fear that these policies may prevent it from spreading.

Please, @aeneasr, can you reconsider opening this issue or creating a new one for a future kratos version?

Thanks.

[frederikhors]

I would also like to point out this.

On the https:/thomasdarimont/awesome-keycloak#miscellaneous page the first link is:

"Find sites using Keycloak with google": https://www.google.com/search?q=inurl%3Aauth+inurl%3Arealms+inurl%3Aprotocol&oq=inurl%3A&client=ubuntu&sourceid=chrome&ie=UTF-8

I don't want this for Kratos, please.

[aeneasr]

Given the other information provided in this thread, the setting would not offer any additional benefit. It's very easy to find out that Kratos is running. The link you just provided for Keycloak is as valid for ORY Kratos as well. Just search for inurl and /self-service/browser/flows. The same applies by the way to a lot of other software, including Okta, Auth0, and so on.

Since there is no inherent value to hiding the cookie name, because it's actually much easier to just use Google Search (as demonstrated) the downsides (e.g. making sure to use the same cookie name in your passthrough config / proxy config / ...) outweigh the benefits in my opinion.

If you don't want to run an open source project and maintain and upgrade it, I recommend getting in touch with us as we will provide a cloud service that reduces risk exposure caused by missing patches.

[sagikazarmark]

Personally, I think this is an easy fix and if someone wants that level of "security", URLs can easily be rerouted in proxies, changing the cookie name on the fly is a bit harder.

While I would change the cookie name, because it's just there and obvious, I probably wouldn't go that far, to change the public URLs as well.

Anyway, I guess PRs are welcome. 😄

[aeneasr]

URLs can easily be rerouted in proxies, changing the cookie name on the fly is a bit harder.

Unfortunately not! Without changing the paths internally that won't be possible as redirects will not work and so will the router!

The problem I have with this approach is that it does not provide security or rather it provides a false sense of security. It tackles the problem from a direction that doesn't make a system secure. Instead, someone will feel "safe" because the cookie was renamed and just don't upgrade when it's required because "no one know it's running".

But that's the wrong approach. Figuring out what software is running is so easy. The whole flow from initializing the request, to redirecting to the login (if ?request=...) screen, to going back and posting the data, it's so easy to track what system is being used! If Kratos hits some type of critical mass, enough tools will be out there to identify it - as is the case with identifying Keycloak or any other popular service (just look at shodan.io).

I know that the code change is minimal, and that the discussion probably much more work than just implementing it, but in this case this is about security practices.

In an ideal world, there would be a "conceal" mode but I have yet to see a front-facing service that you can interact with that is capable of doing that. Obscurity (eg DRM) is not a long-term effective security practice!

[frederikhors]

@aeneasr, I agree with you on everything except what you say about the updates.

Customizing the name of the cookies and the name of some paths does not mean no longer updating the dependencies.

All of my software have bots that continuously search for updates to be applied.

[aeneasr]

Customizing the name of the cookies and the name of some paths does not mean no longer updating the dependencies.

I know, but we have provided security software for companies over 5 years now and we regularly see behavior like that. It doesn't man that that's the case for you!

Our security policy is very tough and our median resolution to security issues is well below 24 hours merge from report to release. If you haven't, sign up to the newsletter here where we announce important releases!

I'm still open to figure out if there is some type of cloaking mode that we can use but it would need to cover at least the following areas in order to be worth the implementation and actually useful!

Possible

• Prevent discovery through headers:
  • Using obscure cookie names for CSRF, Session, and others
  • Obscuring/censoring any other headers (e.g. Served By, Via, ...) that might expose information
• Add robots.txt to the index to prevent good bots (Google, but not Shodan) from indexing
• Altering router URLs (e.g. /self-service/login/...) on a config-level which requires serious, heavy lifting and refactoring and a lot of room for configuration or admin error.

Impossible

• Obscure challenge/response pattern (redirect to login?request=...) - this is impossible because we rely on challenge/response patterns to perform a lot of the security mechanisms you would otherwise have to implement yourself.
• Obscuring payloads from the public API (e.g. /sessions/whoami)

I think that, without hiding the public API completely it will be almost impossible to pull off any of this. Hiding the public API effectively means that you can't use any of the browser-based flows provided by ORY Kratos which makes it pretty much useless IMO.

[radykal-com]

👍 on allowing the session cookie name customization.

In our case, kratos will be behind an api gateway (KrakenD) and all of the known paths and redirects coming from kratos will be translated to other ones, and those ones will be translated again when routed back to kratos. For a lot of companies security and information disclosure regarding the software they run is a very high priority. Making the cookie session name configurable should be an easy task.

[aeneasr]

We encountered a use case where it makes sense to scope the cookie name for sessions in order for multi-domain set ups to work, reopening.

[Sytten]

Just a small comment to let the team know that it should probably be added to the documentation. I was looking for this feature.