Need suggestion on issues mapping with wstg: Authenticator strength and Identity control issue

[Bankde]

What would you like added?
I'm not sure how these issues can be mapped into the current wstg. I may have missed it or the current wstg does not cover it yet? I don't know. Any suggestion is appreciate.

Both of these issues are not about MFA. They're the main authentication factor and identity.

1. Is there an issue that covers App using weak Authenticator Types (Improper main authentication factor)?

For example, the app logins using username and birthday. It's very weak and may be able to map into WSTG-ATHN-04 or WSTG-ATHN-07? NIST is more coverage about the Permitted Authenticator Types. I currently could not map this issue to the wstg. Only related part I found is in 04-07 that a authentication vulnerable to brute-force is an issue. However, if the app uses Biometric as a main authenticator (which fail to comply NIST) then I could not find any wstg topic to map with.
I'm not even sure if this is something others raise as an issue during a pentest process?

2. Application allows changing email without password confirmation in authenticated session.

This is related to Authenticated Password Changes that requires a user to re-authenticate before allowing them to change the password. However, when the app allows changing the Email without re-authentication and the email can be used for "password reset", the attacker can bypass the need to provide the old password by changing the email and jump to a reset password flow instead. Most applications rely on Email but I think it's actually "identity" in the broader term.

In my opinion, changing anything related to the user identity (email, name, passport id, etc.) should also require re-authentication. But I can't find anything quite like it in the checklist.

Would you like to be assigned to this issue?
Check the box if you will submit a PR to add the proposed content. Please read CONTRIBUTING.md.

• Assign me, please!

Not sure yet how it will come out. Willing to contribute although I'm not the English main.

[rbsec]

Application allows changing email without password confirmation in authenticated session.

This is definitely a good addition - perhaps expanding the current text about requiring re-authentication when changing passwords to cover re-authenticating when changing anything that could impact on the security of the account (password, email address, MFA settings, etc)?

Is there an issue that covers App using weak Authenticator Types (Improper main authentication factor)?

I would question whether there is really a WSTG issue here, particularly in the example you give. Firstly because biometrics aren't particularly common in web applications due to the lack of browser support. But mostly because SP800-63B may say that biometrics shouldn't be be used as the sole authentication factor - but the WSTG is not designed as a methodology for how to audit an application against NIST SP800-63B.

And while NIST has many good recommendations, it also gives some rather dubious ones. For instance, SP800-63B doesn't allow the use of a hashing algorithm such as Argon2id to store passwords (although it does allow SHA-1...) - but I certainly wouldn't expect a pentester to flag a client using Argon2id as a security issue just because NIST don't like it. And equally, while relying solely on biometric authentication may not be appropriate in some environments and systems, it is perfectly fine in others.

If there are exploitable issues with the implementation of an authentication mechanism, or if that mechanism is fundamentally weak (such a short numeric PINs) or broken then those are certainly worth flagging - but the fact that a US organisation doesn't approve the use of that authentication system isn't a pentest issue (although it may be a compliance issue).

Interested to hear what @ThunderSon and @kingthorin think on this.

[Bankde]

@rbsec whoop my bad, I think I missed a sentence. Another example is using a Birthday to login. I know it's extremely weak, brute-forceable and could be mapped into WSTG-ATHN-07 but it's not quite password. Unlike password that the recommendation is to enforce stronger password, the recommendation for this case should be changing the auth factor to stronger one. I'm not sure if there is any other borderline weak but not-quite-brute-force-able authenticators that could be an example. Currently I don't have any better example yet.

I understand your explanation on NIST part. And agree it's audit job, not pentest. My paragraph was misleading. I added the birthday part into my previous comment.

[rbsec]

Ah, that makes a bit more sense. So things like:

• Weak information like dates of birth/etc.
• Very short things like PINs
• Security questions

I'm not sure they really fit well into any of the existing sections under 04/Authentication - so perhaps a new one is needed?

[Bankde]

Is there an issue that covers App using weak Authenticator Types (Improper main authentication factor)?

or maybe extend the existing section to cover those?
The idea is not completely new. It's just a bit over this and there. Weak Password Policy (WSTG-ATHN-07) is just a bit too focused on password while Multi-Factor Authentication (WSTG-ATHN-11) has some nice content about factor strength but can't be used as reference for a main authentication due to the title name.
It might be possible to extend "Weak Password Policy" to cover other authentication factors by adding another section?

Application allows changing email without password confirmation in authenticated session.

Might be possible to add another section into WSTG-ATHN-09 Weak Password Change or Reset Functionalities. The "Reset Functionalities" part can be seen as coverage for the reset or change process of account's security data.

[alp1n3-eth]

It does sound like a new one might be needed, or WSTG-ATHN-07 could be extended in some way. It does seem like it's more accurately described as "weak credentials" instead of "weak password". It could be kept the same because if the birthdate/social security numer/etc. is used as the only information being entered, it could then be treated as the "password" as it's the only thing standing between an attacker and a user's data.

Or it could be just referred to as a catch-all: "Weak Authentication (CWE-1390)" or "Improper Authentication (CWE-287)". I'm leaning towards "Weak Authentication" due to the CVE examples including coverage for:

• An interface having an empty password to access root shell through its interface.
• A system using a deterministic algorithm to generate utility passwords.

It seems like the closest child of the main CWE pillar that is applicable. I didn't know if it would change based on the use of only a birthday/social security number/etc., vs. those "predictable/knowable" values being paired with a username/email address. "Weak Password Requirements (CWE-521)", "Weak Authentication", or "Weak Credentials (CWE-1391)" all seem like decent options...

I'd be happy to help contribute to this if it's seen as a good addition to the WSTG. Just let me know!

[kingthorin]

I'd support renaming ATHN-07 and adding weak cred details, number 1 in the original issue. For the second original issue, I'd suggest covering that in ATHN-09.

@alp1n3-eth if you're up for tackling either or both of those then go for it. Don't forget to check the contribution guide