3.3.2 reauthentication on session timeout

[Sjord]

3.3.2 If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. L1: 30 days L2: 12 hours or 30 minutes of inactivity, 2FA optional L3: 12 hours or 15 minutes of inactivity, with 2FA

This requirement has several issues:

• It specifies different requirements for each level. We want to simplify the level column (to show just 1, 2, or 3), and having different requirements for each level doesn't fit with that.
• Level 1 is supposed to be pentestable, but a session timeout of 30 days is not always testable without waiting 30 days. So realistically this is not pentestable.
• I am not sure whether this requirement should say anything about 2FA at all. Maybe 2FA should be a separate requirement.
• The low timeouts of 15 or 30 minutes may not give a proper tradeoff between security and reliability. Imagine if you had to reauthenticate to GitHub or Gmail every time you didn't use it for 30 minutes. It would drive me crazy. Also, apparently Google and Microsoft seem to think that having sessions persist for a long time is worth the security risk. So I think we should re-evaluate whether sessions really should expire within 30 minutes.

There was already some discussion about this in Use of non-✓ for level · Issue #1022 · OWASP/ASVS

[elarlang]

Level 1 is supposed to be pentestable, but a session timeout of 30 days is not always testable without waiting 30 days. So realistically this is not pentestable.

I guess we move from "testability based" to "risk based" levels. See https://github.com/OWASP/ASVS/issues/1127

Current requirement is (probably) directly ported from NIST. From there the question is also, do we want to be aligned with NIST or not.

[tghosth]

@Sjord can you tell if the current requirement is ported from NIST?

[Sjord]

Yes, it's literally NIST:

• reauthentication of the subscriber SHOULD be repeated at least once per 30 days during an extended usage session
• Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 30 minutes or longer.
• following any period of inactivity lasting 15 minutes or longer. Reauthentication SHALL use both authentication factors.

[tghosth]

In principle, I would prefer to be aligned with NIST in this case.

For companies that violate the timeouts, I can think of three ways to handle this: 1) We ignore the problem 2) We say that companies who do not want to comply with the requirements should demonstrate sufficient mitigating controls without specifying further 3) We create a new section of requirements you have to implement specifically, if you don't want to implement these timeout requirements.

What do people think, @jmanico @danielcuthbert @elarlang

[danielcuthbert]

Tricky one. I like both #2 and #3, but more so #2 as this makes those who feel longer timeouts are ok but with mitigating additional controls.

[tghosth]

In principle, I would prefer to be aligned with NIST in this case.

For companies that violate the timeouts, I can think of three ways to handle this:

1. We ignore the problem

2. We say that companies who do not want to comply with the requirements should demonstrate sufficient mitigating controls without specifying further

3. We create a new section of requirements you have to implement specifically, if you don't want to implement these timeout requirements.

@jmanico @elarlang what do you think?

[elarlang]

We can not ignore the problem - if large application (facebook, gmail, ...) can handle keeping their users logged in, then there are valid alternative solutions for taking those risks done.

In ideal world we should have solution 3 - we have described requirements how to achieve alternative. In practice, we go for solution 2.

[tghosth]

thanks @jmanico @danielcuthbert any other opinions?

[jmanico]

I prefer we say that companies who do not want to comply with the requirements should demonstrate sufficient mitigating controls without specifying further

[Sjord]

For companies that violate the timeouts, I can think of three ways to handle this

I think this is not the correct approach. Companies that want to have timeouts of 60 days are going to have timeouts of 60 days. They can just ignore what the ASVS says, or implement all of the ASVS except for requirement 3.3.2. Companies can determine for themselves what part they use from the ASVS, and how strict they are sticking to it. Any requirement can be ignored, with or without "sufficient mitigating controls". Every requirement has a way out, and we don't have to specify it with the requirement.

If we do offer a way out for this requirement, we implicitly say that this requirement is stupid and you don't really need to take it serious. If we think that's the case, we should remove it ourselves. Instead of including it but marking it as not really a requirement.

I think we agree that a timeout of 15 or 30 minutes is unrealistic, but we also want to keep aligned with NIST. So either we choose NIST and keep these stupid limits, or we break with NIST and come up with our own timeouts.

Level 1 is supposed to be pentestable

I guess we move from "testability based" to "risk based" levels.

I created Risk-based instead of testability-based levels · Issue #1495 · OWASP/ASVS.

[jmanico]

I do not at all think that 15 or 30 minutes is unrealistic for idle-timeout values for apps like banks and other high risk applications.

[Sjord]

When I am checking my account balance, it's fine if I am logged out from my banking app after 15 minutes of inactivity. For people working at a bank and working with banking software all day, it would be pretty inconvenient if they are logged out after 15 minutes of inactivity.

Furthermore, the bank possibly has a policy that the computer is locked after several minutes of inactivity. Having the application session expire after that is not very effective.

[tghosth]

@Sjord I accept that but I don't think we want to straight up come out against NIST.

I think that we can recognise that both of the following can be true:

1. We need to include a timeout requirement and that should follow NIST
2. It might not be ideal for every use case

I think that as long as we are standing behind most of our requirements, it is ok to specify a couple where it is clear that an alternative approach needs to be taken. This also seems to have broad agreement from the other leaders. I agree that MFA is not really relevant here and will be handled elsewhere anyway.

The original requirement:

#	Description	L1	L2	L3	CWE	NIST §
3.3.2	If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. (C6)	30 days	12 hours or 30 minutes of inactivity, 2FA optional	12 hours or 15 minutes of inactivity, with 2FA	613	7.2

I would suggest one of the two following modifications:

Option 1:

#	Description	L1	L2	L3	CWE	NIST §
3.3.2	[UPDATED, SPLIT TO 3.3.6, 3.3.7] If authenticators permit users to remain logged in, verify that re-authentication occurs at least every 30 days. (C6)	✓	✓	✓	613	7.2
3.3.6	[ADDED, SPLIT FROM 3.3.2] If authenticators permit users to remain logged in, verify that re-authentication occurs at least every 12 hours or after 30 minutes of inactivity. (C6)		✓	✓	613	7.2
3.3.7	[ADDED, SPLIT FROM 3.3.2] If authenticators permit users to remain logged in, verify that re-authentication occurs at least every 12 hours or after 15 minutes of inactivity. (C6)			✓	613	7.2

Option 2:

#	Description	L1	L2	L3	CWE	NIST §
3.3.2	[UPDATED, SPLIT TO 3.3.6] If authenticators permit users to remain logged in, verify that re-authentication is required at least every 30 days for L1 applications or every 12 hours for L2 and L3 applications. (C6)	✓	✓	✓	613	7.2
3.3.6	[ADDED, SPLIT FROM 3.3.2] If authenticators permit users to remain logged in, verify that re-authentication is required after 30 minutes of inactivity for L2 applications or after 15 minutes of inactivity for L3 applications. (C6)		✓	✓	613	7.2

@elarlang @danielcuthbert @jmanico any comments on this? I think Option 2 is cleanest.

[elarlang]

I like Option 2.

If authenticators permit users to remain logged in - what this phrase gives to the requirement (compared to requirement without the phrase)?

Proposed 3.3.6 says clearly that it is about inactivity. 3.3.2 does not say clearly it is for max session lifetime and without reading 3.3.6 it may feel it's for inactivity time.

[jmanico]

I like option 2 as well

[tghosth]

Opened #1660 based on option 2