-
-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: customizable token prefix #733
Conversation
Wouldn't this be easier via a newup function which sets the prefix field then provide the result as the core strategy? |
Yeah, I agree that it seems like it should be easier. I was trying to match what I perceived as the pattern I found in https://github.com/ory/fosite/blob/master/config.go and https://github.com/ory/fosite/blob/master/config_default.go, and then I chased a couple of those examples and tried to mimic them. Can you expound on the better way or is there a similar example? |
Yeah it makes sense why you did it. I think the intention in the pattern was primarily for hot reloading, whereas this probably isn't something that would benefit much from it. We'll see what Mr Hackerman thinks and if he has a preference. |
Hi, thank you for the PR and inititative! Unfortunately, we don't plan on changing this. The point of token prefixes is to allow security scanners to easily scan code for leaked credentials. If everyone does their own token prefix, it makes the whole software ecosystem more vulnerable. Any token leaks will stay undetected if every site decides to use their own token prefixes. Currently, there is no standard for the token prefix format agreed upon (e.g. in an RFC). What I'm open to consider is adding a suffix to the prefix to allow big sites (assuming e.g. github wants to use this) to uniquely identify the token source, which would make it easier for scanners to tell you the token source |
Whoops, pressed enter a bit too soon :) Also wanted to say thank you for the PR and contribution! It always sucks when a feature is not accepted upstream, but I hope the explanation makes sense! |
@aeneasr I know you have previously stated that Fosite is only meant to be used with Hydra but that wasn't my understanding when we adopted it for our own implementation. I believe there are others in the same boat. Would you accept a change where the prefix can be set globally - maybe just a change from The alternative is for us to effectively clone the HMACStrategy and write our own without the prefix and that was my plan until this PR was submitted. |
@aeneasr Thank you for responding. A few thoughts
I understand that I might not change your mind on this. Thank you for your time either way. |
Though I don't think it's feasible to try to hide your usage of hydra, I do agree with @mattslocum, especially considering that services reporting secret leaks will only report to ory, which isn't at all helpful in the case of a self-hosted hydra, where you'd want those services reporting to you... |
@K3das and @mattslocum both make valid points. This has been a point of contention within our organization in order to adopt Ory fully. It is not clear to me how having different prefixes makes the software ecosystem more vulnerable? Organizations with good security posture are already doing their own internal scans for secret leaks. From an attackers standpoint, the ory specific prefix is a gift. I now know that I do not need to waste time determining which Auth/Authz service is being used since information is handed to me in a pretty bow. At a minimum an optional config should be available. This would ease the concerns from Security Teams and allow further adoption. If not, I foresee this will be a limiting factor for orgs to adopt Ory. |
I think this has been done with #816. (It is not customizable, but at least it is easy to wrap it yourself with prefix you want.) |
If this was closed in response to Fosite's #816, then I don't think that is accurate since Hydra is still not customizable. I still think this would be a valuable feature for independently hosted instances to supply a unique prefix so that way ory owned tokens aren't confused with tokens minted through a self-hosted system. |
For Hydra you should open an issue in Hydra repository. |
matching Hydra PR: ory/hydra#3407
#675 added
ory_at|pt|ac
prefixes to HMAC tokens. This is a good feature for detecting tokens in places they shouldn't exist. However, for security minded self-hosted implementations, it is often preferred to avoid underlying tooling providers. In this case, it is preferrable to be able to customize theory
name and replace it with another key.This PR adds ability to customize the token prefix before
at|pt|ac
.Related Issue or Design Document
Related to #675 and ory/hydra#2845.
Checklist
If this pull request addresses a security vulnerability,
I confirm that I got approval (please contact [email protected]) from the maintainers to push the changes.
Further comments
For backwards compatibility for integrations that already upgraded, it continues to remove the ory specific prefix when trimming.