search

ory / kratos

The most scalable and customizable identity server on the market. Replace your Homegrown, Auth0, Okta, Firebase with better UX and DX. Has all the tablestakes: Passkeys, Social Sign In, Multi-Factor Auth, SMS, SAML, TOTP, and more. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.
https://www.ory.sh/?utm_source=github&utm_medium=banner&utm_campaign=kratos
Apache License 2.0
11.24k stars 963 forks source link

Make the session cookie name configurable #268

Closed sagikazarmark closed 3 years ago

sagikazarmark commented 4 years ago

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

Currently the session cookie name is hard coded to ory_kratos_session:

https://github.com/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

just some I quickly found

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

aeneasr commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

I would also like to point out this.

On the https://github.com/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

Impossible

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 commented 4 years ago

👍 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 commented 3 years ago

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 commented 2 years ago

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