1.2.4 is confusing

[jmanico]

1.2.4 could use significant clarification and simplification

[tghosth]

So this is actually an interesting point and one that is actually really important.

1.2.4

Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.

I would change it to:

If the application includes multiple authentication pathways, verify that security controls and authentication strength are enforced consistently across all pathways and that this is explicitly documented.

[elarlang]

it would be nice, when requirement text starts with "Verify that ..." :)

[tghosth]

Fine:

Verify that, if the application includes multiple authentication pathways, security controls and authentication strength are enforced consistently across all pathways and that this is explicitly documented.

Better? :)

[tghosth]

Opened #1455, can @elarlang and @jmanico review?

[elarlang]

From proposal: https://github.com/OWASP/ASVS/pull/1455/commits/1b68e65307c95f2e9f4d360921ee227379745ccb

#	Description	L1	L2	L3	CWE
1.2.4	[MODIFIED] Verify that, if the application includes multiple authentication pathways, security controls and authentication strength are enforced consistently across all pathways and that this is explicitly documented.		✓	✓	306

Here are 2 requirements combined - implementation check and documentation check.

For v5.0 I try to remove all implementation requirements away from V1 (see #1063).

In case we want some clear outcome from documentation as pre-condition for further testing, then it makes sense to create also clear separate requirement. If we don't need this information for further testing, it's just a noise here without any actual meaning.

[jmanico]

I suggest we just drop this less-than-clear requirement.

[tghosth]

I think this is a conceptually important requirement, I think it addresses a specific problem and I think it is definitely an architectural level thing, even if it has a practical implementation as well.

In this particular case, I think the successful implementation of this requirement would be next to impossible to check without documentation.

@elarlang do you think: a) We should have two separate requirements for Documentation and Implementation b) We should make this a more documentation focused requirement? c) Something else?

[elarlang]

I think I would use another "inventory + implementation" combination here.

(wording is not candidate for proposal) V1.2.* Verify that all the authentication ways are documented V2.* Verify that all authentication pathways are done the same way/strength and there is no another, non-documented way for authentication

[tghosth]

So maybe:

v1.2.4 Verify that, if the application includes multiple authentication pathways, these are all documented together with consistent security controls and authentication strength.

v2.x.x Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently.

Are you sure this is not too much duplication?

[elarlang]

At the moment those seems similar, but this is the only way how to solve it if we want to have supporting/pre-condition documentation requirement for implementation requirement.

From 1.2.4

these are all documented together with consistent security controls and authentication strength.

What is the expected outcome from this documentation?

[tghosth]

I guess the idea of the documentation is that it makes clear:

1. What different authentication pathways exist
2. The security controls which should be enforced consistently for each one.
3. The authentication requirements/stages which should be enforced consistently for each one.

Does that make things any clearer?

[elarlang]

Let's get them in and if needed, we can finetune them later.

[tghosth]

Updated #1455

[elarlang]

Approved, but didn't merge. Left it for @jmanico to comment