3.3.2 - Update to correspond to NIST SP 800-63B revision 4 draft

[ryarmst]

Branching from #1557.

#	Description	L1	L2	L3	CWE	NIST §
3.3.2	Verify that there is an absolute maximum session lifetime such that re-authentication is required at least every 30 days for L1 applications, every 24 hours for L2 applications, and every 1 hour for L3 applications.	✓	✓	✓	613	7.2

Notably, the wording around timing has been relaxed. Does anyone have an opinion on whether the requirement reflect this (see below)?

In the previous version (AAL2):

At AAL2, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity.

In the revision 4 draft (AAL2):

A definite reauthentication overall timeout SHALL be established, which SHOULD be no more than 24 hours at AAL2.

I'll create an issue for the inactivity timeout requirements following any discussion here.

Additionally, are CWE and NIST references going to be kept for V5? The NIST ref will need to be updated if so.

[tghosth]

I think we will drop the references from the table of requirements although I think it would be good to try and keep a reference to them, maybe in the surrounding text of each section.

[tghosth]

Happy for you to PR this and we should reference somewhere the version of NIST that we relied on

[randomstuff]

every 1 hour for L3 applications.

This is quite drastic.

ASVS Level 3 is for the most critical applications - applications that perform high value transactions, contain sensitive medical data, or any application that requires the highest level of trust

Many users of applications which contain sensitive medical data would find it difficult to accept that they must reauthenticate every hour.

For example, ProSantéConnect, a French IdP for health practitioners (i.e. access to sensitive medical data) enforces reauthentication after 4 hours.

[elarlang]

@randomstuff - the referenced requirement in the opened issue is the requirement as it stand at the moment (not proposed requitement).

This issue is about to make the requirement flexible based on documentation requirement, see https://github.com/OWASP/ASVS/issues/2076#issuecomment-2366885250

[elarlang]

Reading it again, maybe it's not that clear. @ryarmst - we should not discuss here what are the fixed values, as we solved it with documentation, only thing what we should say with this requirement is something like:

Verify that the user's session maximum inactivity period and maximum session lifetime before requiring re-authentication are implemented based on documented decisions.

[ryarmst]

@randomstuff Sorry, this was an error/typo on my part (it's 12 hours for AAL3). It should be:

#	Description	L1	L2	L3	CWE	NIST §
3.3.2	Verify that there is an absolute maximum session lifetime such that re-authentication is required at least every 30 days for L1 applications, every 24 hours for L2 applications, and every 12 hours for L3 applications.	✓	✓	✓	613	7.2

@elarlang Regarding fixed values, I would agree that there is room to relax the requirement, especially considering NIST is relaxing timings from SHALL to SHOULD in some cases (though not all).

From NIST (the new draft):

• AAL1: "SHOULD be no more than 30 days at AAL1"
• AAL2: "SHOULD be no more than 24 hours at AAL2"
• AAL3: "SHALL be no more than 12 hours"

That said, I would argue against collapsing/relaxing requirements. From a testability point of view, your proposed requirement is impossible to evaluate without documentation.

[elarlang]

That said, I would argue against collapsing/relaxing requirements. From a testability point of view, your proposed requirement is impossible to evaluate without documentation.

I don't get it.

We (will) have documentation requirement via https://github.com/OWASP/ASVS/issues/2076#issuecomment-2366885250

Verify that the user's session maximum inactivity period and maximum session lifetime before requiring re-authentication are documented and are appropriate in combination with other controls

and my comment https://github.com/OWASP/ASVS/issues/2113#issuecomment-2374035032 points to that with proposing direction

Verify that the user's session maximum inactivity period and maximum session lifetime before requiring re-authentication are implemented based on documented decisions.

If we want to set directions with time limits per level, it should belong to documentation requirement, otherwise those two proposals are in conflict - if documentation asks you decide based on your own risk level and implementation requires to user numbers from NIST.

[ryarmst]

We (will) have documentation requirement via https://github.com/OWASP/ASVS/issues/2076#issuecomment-2366885250

Yes, but I am thinking about this from my POV consuming the ASVS as a tester:

1. Documentation is typically not available.
2. Even with access to developer documentation, I suspect most teams will not have satisfied V1 requirements. We are then left to come up with our own standards for what session timeouts ought to be whereas ASVS V4 previously at least provides reference points for apps based on level that can be referenced (we always referenced NIST nevertheless, but I think ASVS should fill this role to the extent that it can).

In general, I don't like the pattern "define timeouts to be whatever is appropriate, then confirm they are implemented as intended" as I think ASVS should be somewhat more opinionated.

If we want to set directions with time limits per level, it should belong to documentation requirement, otherwise those two proposals are in conflict - if documentation asks you decide based on your own risk level and implementation requires to user numbers from NIST.

Good point and I think I have a solution that should satisfy both of us. I will propose modifying the documentation requirement to something similar to "verify intended timeouts correspond with NIST and are documented otherwise document reasoning for exceptions". I would split the doc requirement into two (inactivity vs. absolute) and add references to the present NIST requirements (the actual timings). Then, the V3 requirement can be something like (simplifying for now): "Verify that timeouts correspond to NIST requirements and recommendations or the overriding timeouts specified within design documentation."

Does this make sense?

[elarlang]

Without documented decision you can not develop and you can not test. It quite strong pre-condition built in for many requirements (take a look over V1).

Also I proposed, that to cover NIST levels as fallback to the documentation requirement.

I'm not from that religion who takes everything as pure gold from NIST and also we don't have any reason to take everything one-to-one from NIST. If it makes sense, we take it, if it does not, we don't. As something is presented in NIST, there is most likely a lot of brain-work behind that, but let put the context to NIST audience (gov oriented) that may not present well the entire Internet). In short - we don't need to be 100% aligned with NIST.

You can stay logged in Gmail, Facebook, X, ... quite a long time. Gmail can be considered high-risk solution, would you like to log in there for example every day? Can you force everyone to do that? Are there other ways to mitigate the risk and not "being compatible" with NIST?

I can re-explain it via some call.

[tghosth]

@elarlang @ryarmst can I suggest you arrange a quick 1:1 call to talk through this point?

[elarlang]

@elarlang @ryarmst can I suggest you arrange a quick 1:1 call to talk through this point?

It is planned.