Where to move or what to do with V3.5 section (tokens section in session management chapter) #2384
Comments
|
My order of preference:
|
tghosth
added
1) Discussion ongoing
|
I do not have a strong opinion here as I do not see a clear obvious location. Option 3 - @elarlang I have agreed with your point that many of these requirements are fundamentally validation issues and that V5 logically makes sense, but I don't think anyone looking at the ASVS for the first time would expect to find it there. Option 1 - The more I think about this option, the more it seems reasonable especially thinking about implementation and testing. @tghosth I do think if it moves, there ought to be guidance text in V3 for those who expect to find it there. |
|
Would including "Cryptographically Secured Tokens" as a section of "V6 Cryptography" be weird? |
Yes, for entire section it is weird. I would like to get out everything from V6 that is not a clear crypto problem or the "main problem to solve" is not a crypto problem. For that discussion we have #2375 (comment) |
|
Making the "Option 1" more clear. VX.1 Token source and intgrityBefore validating the token content there is a need to verify, whether the token is initiated by a trusted party and if it is not tampered.
Related open issues:
VX.2 Accepting stateless token contentBefore accepting the token content there is a need to validate if the token is in a valid time window and meant to be used for the given service and for a given purpose to avoid cross-usage over different services and token types from the same issuer. Specific requirements for OAuth and OIDC are covered in the dedicated chapter.
Related open issues:
|
|
Hard to choose! I think option 1 is worth a try, sounds logical to have things closely related to APIs and Web Services together. I will try to explain how I reason about it. If we do option 1 (or 2), then you could look at ASVS chapters as 3 main tracks: Track 1, if your focus is a "classic" web application where users login, then it seems logical to look in V2 for user authentication, V3 to deal with user sessions, V4 for authorization and then V5, V6, V7... etc for more validation things that applies to your application. Track 2, if your focus is integration APIs (service-to-service), you can basically skip V2 and V3 and start with V13 for general API and Web Services verifications, V14.7 for authenticating the service/client, then the new "cryptographically secured tokens" chapter (perhaps V15) for authenticating requests to the API , and then V4 and V5, V6, V7... etc. Track 3, if the application use OAuth/OIDC, both tracks 1 and 2 apply, together with V51. I'm not sure if it is good to think this way, but it is one way to look at how to organize ASVS chapters! |
Yes, the thing is that this does not feed neatly in "authentication" nor in "authorization" (because it can be both). On the other hand, these considerations overlaps greatly with certificate validation requirements (because a JWT token, a SAML token and a X.509 certificate are basically the same thing and JWT or CWT are sometimes used as certificates. That being said maybe option 1 (a "Cryptographically Secured Tokens" chapter) would be fine. This chapter might be expanded later on to cover (if need be):
|
|
At the moment "Option 1" seems the way to go, but I think we should get the understanding of the topic and focus aligned first. Tokens are just a format for delivering a message between parties - it's just a technology, it is not tied to authentication, authorization, or session management. It is a separate thing often used to provide other functionalities. So the separate chapter serves that goal. A thing that bothers me is the discussions here are too cryptography-oriented. Cryptography is used to provide the confidence for separate parties, that the token came from a trusted party and is not tampered with. It is the important corner-stone for this, but at the same time - that is it. It is just one important part of the topic, but it is not the topic. Validating the source and integrity gives the possibility to not keep the state for that information and that is why the rest of the world calls it stateless. Why this term is not good for us, is still not clear to me. The point for the token is to be stateless - cryptography is just a solution to make it happen. I don't think it deserves the name for that. All this crypto part is important only for those few requirements that handle the source and integrity, as displayed in #2384 (comment) in section V1.X. After those checks, there is a need to validate the token's meta info, and then it is possible to validate and use the token's content. That means we should not carry the crypto requirement forward to other requirements, as it is already checked as a pre-condition. We have had this discussion also in some other issues #2182 (comment). |
|
Ok, I support Option 1. It sounds like the chapter heading would be something like "Stateless Tokens". As discussed with Elar, the goal is to be stateless and "cryptography" is just the mechanism to achieve this. |
|
Before I go for the PR, I would like to get "pong" from @randomstuff @ryarmst and @TobiasAhnoff . Any strong arguments against this direction? |
|
I support Option 1, but I think "stateless" is worth discussing some more...should we do that here before we decide on Option 1? Or should it be part of a new issue for title and chapter text (given the new Option 1 chapter)? There are some things about "stateless" that I feel are not clear to me, but I need some more time to be able to write something that is good input for the discussion :) |
|
Option 1 sounds nice but actually I thinking restricting to stateless tokens as opposed to tokens in general might be problematic as many requirements might apply to stateful/opaque tokens as well? |
This issue is about (re)structuring the current V3.5 content, so this issue here suits well.
Yes, that is true and the main question here is, how to set the focus or priority for the chapter. If the focus is for crypto, then I can understand and agree with your previous question, that crypto-related requirements may belong to V6. For me, the topic here is stateless information transfer between services. At the same time, if we watch requirements we have at the moment in V3.5, only 3 of them are about crypto, the rest (at the moment also 3) are about token content/metainfo validation.
If we could call it "Token Security" or something like that, for me it feels too vague. But at the end, it is just a question how we set the logical scope for the structure and what kind of requirements are suitable for that. In short, I repeat my current position - the topic I want to cover here is stateless information change between services (in a way, for stateful we have V3), crypto is important part for provide integrity check, but it is not the main topic. |
This is not the case in many applications I have seen where this content (existing requirements) would apply (either not fully stateless, or not for collaboration of different services). To give a counterexample, 3.5.3 and 3.5.5 could (and perhaps should) apply to tokens that use stateful session (or other) identifiers, but are secured with a signature. Other requirements could apply as well and I am sure there are many scenarios where some state information is captured in tokens and some is stored by some server. I think "Token Security" is a fine option, but I do agree that it is vague (hence the use of Cryptographically Secured Token). If the emphasis on cyrptography is at issue, what if we modified the definition to just "Secured Token"? There is existing terminology that is similar (like OAuth's Self-Encoded Tokens), but IMO it fails to capture the diversity of implementations that I think we ought to have requirements for. Ultimately, however, as long as the terminology is defined and consistently used, I am less concerned about what naming is chosen. We have this challenge precisely because there is no clear precedent in the industry (mostly just confusion - see the previous debates over "stateless"), so as I have mentioned before, I think ASVS has the opportunity to set a more clear standard. |
Important is to keep in mind that we don't talk about sessions here. Crypto provides the possibility to have the information stateless. If someone uses the same method for stateful token or opaque string, it does not make the concept of stateless token invalid. |
|
You can all throw in (here, or in slack) scenarios that you feel are not covered by current proposal AND are covered now. The goal is to have everything covered without any confusion. |
|
I think "Token Security" or something else with Token is good, like "Token Management" or "Token Request Authentication". I also think it would be logical if the Session chapter had the same kind of title ("Session Management", "Session Security" or "Session Request Authentication". The way I see it is that first you have either "User Authentication" (V2) or "Service Authentication" (V14.7). Then, depending on application requirements, you can do authentication on every request (not good for human users, but might be fine for services) or authenticate requests using either a session (V3) or a token (new chapter). The session chapter contains all requirements that are expected when managing a session, like creation, termination, inactivity timeouts etc. The token chapter contains all requirements that are expected when managing a token, like validation, expiration etc. This works but perhaps gets somewhat confusing...since both sessions and tokens can be regarded as "stateless" or "stateful" solutions. A session can have only the session id in a client-side cookie or custom header, and a token, in example an OAuth reference token, can be just a secure random string providing access to some server-side "state" (the token claims/properties). While a JWT typically has no state on the server-side that needs to be shared between all server instances (except perhaps key material needed to validate the token), and you can also have a session without any server-side state. An example of this is .NET, where you by default get an encrypted cookie (or set of cookies) containing e g a GUID, session data (claims) and maybe even access and refresh tokens (if also using OAuth/OIDC). This session mechanism is "stateless", since (just as for a JWT) the only thing that need to be shared between server instances (to authenticate requests and provide information needed for authorization) is the key material (all client-side state/stateless session/tokens need to be integrity protected in some way). The main difference is where state is stored and if it is expected to behave as a "session" or as a "token", e g if there are requirements on termination. A "stateless" solutions can´t be terminated like a "stateful" one (a good example is OAuth access-tokens, when using reference-tokens they can be revoked instantly, while JWTs are valid until they expire). So maybe one way to see it is to have one chapter for "Authentication of requests with server-side state" and one for "Authentication of requests with client-side state (a k a stateless)"? This might be explained in chapter text and titles can still be "Session Security" and "Token Security", since we often associate server-side state with "sessions" and client-side (stateless) with the term "token". Or, we can have titles that reflect this, perhaps something like "Server-side State Security" and "Client-side State Security", but I think I still prefer "Session Security/Management" and "Token Security/Management" (and having chapter text that explains "stateless" and how the two chapters relates to each other) This might be a good idea or not...I have not had time to analyze how something like this would affect current requirements and organization, perhaps not that much, perhaps mostly chapter texts and where things are put... This is a hard one! |
|
Having read the above, I see the challenge of the term "stateless" and the challenge of the term "cryptographically secured". Maybe an alternative heading could be "Trusted Tokens". I don't think this is an industry term but I think it captures the whole point here which is that we are relying on values included in the token. |
|
Please give me some more hour(s) to prepare the points. Meanwhile I recommend to read the issue content written so far - scope: (stateless) tokens only. No session management or other functionality involved. |
|
Sometimes I feel like my comments are not reaching GitHub. For example, explaining, that the topic here is not about session management (#2384 (comment), #2384 (comment)) So I make my points referenceable. update 2024-11-25: proposal by @randomstuff in #2384 (comment) provided better term than "stateless token" - "self-contained token". This carries more precisely the idea behind that. All the points balow are still valid, just instead of "stateless" should be read "self-contained".
My first preference is to solve "Point 10" - revert the scope change for crypto-related requirements to be stateless tokens oriented. Actually, the question is - are they by content wide enough to be valid outside of the stateless tokens section or it is just the attitude towards them? E. g. the validation question - are those ready to be moved to V6 as they are? If it creates a gap or not covered area, it should be considered to have a separate more general requirement into V6 to cover that - as we have more general requirement in current V3.5 to have abstract requirements and specific requirements in the OAuth section to cover the special need. This proposal satisfies: Point 5, Point 14, Point 15 If the first preference is "voted against"
This does not satisfy points:
In summary, I find it to be not aligned (filtered) that I need to explain the scope for the section that was conflicted with a questionable move. And now there seems to be an attitude that everything else must be aligned with the questionable move going against many listed points (e.g. 2, 3, 5, 9, 14, 16). |
Agree
I think the point was made above that (right or wrong) you could have a system that uses "stateless tokens" but also relies on some sort of server side state (I am not using the word session here). This is why I suggested that maybe the word "stateless" is not 100% accurate despite being industry accepted and that trusted token might more accurately represent the situation. Again not session management specific.
3.5.3 and 3.5.5 explicitly refer to tokens, I am not sure what here would be considered "wider than stateless tokens". Do you mean that these requirements were expanded to not just be relevant to "session management" but trusted tokens in general?
Agree
I don't think there is significant conflict here, I think it is just a subtle terminology question about what stateless means, as noted in my response to Point 3.
I think there is a terminology thing here. Broadly speaking, I think that the new chapter should cover a situation where we rely on the contents of the token to make security sensitive decisions. The alternative is that the token or whatever is just an ID which is used to look something up at the back end.
I think that Server-side State != Session but given my response to Point 20 we could side-step the issue by not referring to "state" in the name of the chapter.
I don't really understand what you are proposing here. From reading the comments, I think we all agree that these requirements can be moved to a dedicated section and there is just some discussion on the specific scope and definition. In summary, I think we need to create a new chapter and move the token requirements over. I think we can argue about the specifics afterwards. I think your arguments above support my suggestion to refer to them as Trusted Tokens :) |
|
@elarlang if you feel this still needs discussion, I think we need to get a call together next week. |
I also responded to that above, that if you use content from stateless token to keep the state, does not make the concept of stateless token invalid and it does not change anything of the process of validating it. In other words, does not change the scope of this issue/chapter.
Examples from this thread:
|
|
As @tghosth noted, I think it is primarily an issue of terminology. I will focus just on a few key points of disagreement:
Even this definition is exclusionary of implementations where there is only a single party that creates and consumes tokens, but otherwise I am in agreement.
I do not agree. Can you provide a reference to a single definition that is widely accepted? I think the fact that there have been so many issues related to this is strong evidence that there is disagreement over what this precisely means and what types of tokens technically qualify. Issue #2100 was a discussion focused on terminology and then #2204 was a subsequent discussion and update to use the term "Cryptographically Secured Token" to refer specifically to tokens with self-contained information where integrity must be guaranteed. It just so happens that cryptography is what allows us to do this.
The scope of these requirements was not changed. The terminology was changed due to the lack of clarity in using "stateless". The requirements should apply to all tokens with self-encoded information where integrity must be maintained. I am not attached to the definition above, but I do think that "Stateless Token" is overly narrow. I agree that the new section should not be specific to use cases such as session management, but it should nevertheless apply to the relevant tokens (tokens where we guarantee integrity using cryptography). |
You can challenge the claim, but, little Google test:
All the issues were related to "stateless session" and that is completely different issue to discuss. The main reason to propose this move, is exactly to solve this confusion and issue. I call you recheck points:
Also worth recheck Point 21. It is very important to point out again.
There are some lines in conflict with that descibed below. Also, I answered to this here: #2384 (comment)
As described above, lack of clarity of "stateless session" should not be carried to "stateless token".
And we are back with the question, opaque tokens are in or out? "Scope was not changed" vs Point 5 + Point 20.
I'm not convinced :)
This is the intended goal for the proposed section. I'm waiting for scenarios that are not covered by these proposed changes. Called it out here #2384 (comment). It should be easy to provide if there are obvious ones. Sincerely asking as there can be a risk of missing something and leaving a cap to the coverage. If there is need, we may need to create some more abstract requirements to V6, as proposed in #2384 (comment).
Again, session management is a separate topic. That is the problem to solve with this.
I find this line to be in conflict with previous statement that "scope was not changed". This is the scope change. See point 8, and maybe also Point 12. And in general, I also pointing to my previous comment: #2384 (comment) |
|
@elarlang Sorry if this is hard to read, but I am keeping sections matched with your last response.
I do not interpret the results here as favoring either case. A search for "stateless token" returns (for me) a mix of results with different meanings and no standard definition from anything that might be considered authoritative. Google's new "AI Overview" (which is displayed first for me) even returns this: "A stateless token is a token that is used in stateless authentication, a method of user authentication that doesn't involve a database" If we accepted this definition, it would be tied to specific use cases. I assume we don't wish to prohibit involvement of databases. This has been one of the sources of debate over these types of tokens because many uses in practice may not be "fully stateless" even though some elements (attributes/properties/whatever) are. Interestingly, the "AI Overview" definition continues (emphasis mine): "What it is This was the initial terminology that seemed promising to generalize these types of tokens before further making them less exclusionary by changing "signed" to "secured" to acknowledge that other techniques (like HMAC) can be used to secure the integrity of these tokens. Yes, some results from a Google search yield NFT content using this term, but many (perhaps most) do not (determined from scrolling, not a systematic analysis).
I have not claimed that the proposed section must reference sessions or include session-related requirements. Developers using tokens secured with cryptography to maintain integrity of token attributes for any purpose should be able to utilize the requirements of the proposed chapter as appropriate. If a developer wishes to maintain the integrity of some stateful session identifier with cryptography (like using a JWT), then all present V3.5 requirements could apply depending on the implementation, but the token would not be stateless, only some attributes/values may be (if we take the meaning of stateless to be roughly: "the server does not store data or other information"). I am in agreement that we could consider 3.5.3 and 3.5.5 out of the scope of this proposal, but other V3.5 requirements would still apply in this scenario, yet the token would not be fully stateless.
I must not understand this point because it seems to me to be a terminology change. Consider this definition in the Glossary:
From my reading, this implies that stateless attributes are necessarily involved, but perhaps it is unclear or overly broad?
This was not the case. "Stateless token" was changed to "cryptographically secured token". In fact, "stateless token" is what I believe introduces lack of clarity for reasons I have indicated.
I would also like to point out that "opaque token" is another conflicted term that I raised issue over here #2100 (comment) ;). That said, I think any token should be in scope as long as it transfers one or more attributes/values statelessly by guaranteeing integrity. Would you still consider 3.5.3 out of scope for the proposed section if it was reverted? "Verify that stateless tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents." If yes, then this is simply a question of terminology.
I promise I am not attached to the term :) However, I think "Stateless Tokens" is bad for the reasons I hope I have clarified. In order for the chapter to have broad applicability, I think it should be clear that it concerns tokens that capture and guarantee stateless information. From #2384 (comment):
Up until the "between services" I am in agreement unless the intended scope is purely stateless tokens. I think a clumsy, but more appropriate title would be: "Stateless and Partially Stateless Tokens". I believe I have already presented scenarios.
I think I understand your contention here as "tokens where we guarantee integrity using cryptography" could include tokens that do not transmit any information statelessly. This was imprecise on my part. Is this more suitable: "tokens where we guarantee the integrity of stateless information using cryptography"? |
|
(This comment is only about terminology only related to "stateless Tokens".) What about "self-contained token"? I like the opposition of "self-contained token" vs "reference token". This opposition quite makes sense. Discussion:
Random selection of sources using "self-contained token":
Another terms, we discussed was self-encoded token https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/ (kinda meh to me but this is the term using in the OAuth specs). The main argument against this one was by @ryarmst:
|
|
I was preparing the answer to Ryan and struggled to define the difference between "stateless token and stateless service" and "stateless token used in stateful service". I think "self-contained token" vs "reference token" makes sense and solves the definition struggle. I agree with the "Discussion" section as well. |
|
Response to @ryarmst TLDR: if you agree that "self-contained token" should be used instead of "stateless token" and "cryptographically secured token" you can skip reading the rest of the comment. I'm going to use self-contained token instead of stateless token, because it describe better what it is about without forcing a use-case (stateless service). It also means, "stateless token" vs "cryptographically secured token" discussion is irrelevent now and it is replaced with "self-contained token" vs "cryptographically secured token" My main point about the scoping stays:
and
I think it is well covered by "self-contained token" definition and matches with points:
Yes, then it is in the scope (better to use "self-contained token") and no, it is not simply question of how to name it - "
Probably some arguments are removed if to use "self-contained token" instead of "stateless token". I can not see any reason to use "cryptographically secured token" over them.
The token IS stateless, the service is not. This is now covered by "self-contained token" definition.
To be more precise, 3.5.3 and 3.5.5 are not out of scope, but wider, than the scope. Other requirements belong to scope, as was also initially highlighted in point 12.
It matches the points 1, 7 and with defined "self-contained tokens". |
|
@elarlang @randomstuff I think "self-contained token" is just fine if we are clear about what qualifies. If everyone agrees, I will open a separate issue to update terminology via the glossary so that there is a shared definition going forward. Regarding 3.5.3 and 3.5.5, I see two options:
If (2) is preferred, then we will need to consider whether additional requirements are needed for signed/secured tokens that are not self-contained tokens, but that is separate to this issue. |
|
So the proposal is aligned with my proposal, just in switched order: #2384 (comment). For making a decision about moving or not moving requirements, we first need to have them (updated) - so waiting for:
As it is corner-stone for API security, I prefer to have specific requirements for self-contained tokens. At the same time, if those are not specific to self-contained tokens and can easily applied to whatever, we need to recheck the duplication part and the structure. |
tghosth
added
4a) Waiting for another
There has been discussions here and there, what to do with V3.5 section. Mostly I have opened the topic in
Problem to solve: stateless tokens or "cryptographically secured tokens" as those are named now in requirements, are a wider topic and are not limited to sessions. Additionally, using stateless tokens for session management causes many new challenges for achieving the expected solution to fulfill security requirements.
Options are:
The text was updated successfully, but these errors were encountered: