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

[alp1n3-eth]

@kingthorin Yeah, I can totally cover them. I'll take a look at the contribution guide then get cracking. Just to review:

Deliverable 1:

• Rename ATHN-07 to "Testing for Weak Credentials".
• Cover weak credential details in the "Summary".
• Add step(s) to the "How to Test" section.

Deliverable 2:

• This will be for ATHN-09
• Add details to cover requiring re-authentication if any identity-related value is changed (email, phone number). Essentially anything that is utilized in the password reset flow needs re-authN before it's allowed to be changed.
  • This will be added as an H3 under the "Authenticated Password Changes" section.

I'll start putting the changes together. If anything from the above doesn't sound quite right, just let me know, or it can also be addressed within the pull once it's issued.

[kingthorin]

@alp1n3-eth sorry for the delay. Yes that sounds like the right plan to me. I'd also suggest doing it in separate PRs to make things easier to review and prepare.

@rbsec @ThunderSon any thoughts/freedback before @alp1n3-eth starts?

[rbsec]

@kingthorin sounds sensible - I think that my only comment would be around the (always tricky) question of naming.

To my mine, "testing for weak credentials" makes me think about things like default passwords, or users setting things like "Password1" or "12345" - but I think the issue we're talking about here isn't the the specific credential (e.g. the password) is weak; but that the type of credential (e.g. PINs, dates of birth, security questions, etc) are weak.

I'm not entirely sure what I'd call it though. Weak authentication methods? Weak credential types?

[ottosulin]

@rbsec NIST uses the broad term "Authenticators". But would "Weak authenticators" be understandable? It would be canonical with the NIST terminology. To be more in line NIST terminology, I would vote of your suggestions for "weak authentication methods".

[kingthorin]

Maybe it's just me but when I see "authenticators" I generally think like physical device, maybe that makes me show age but 🤷‍♂️

I think "weak authentication methods" seems better.

@alp1n3-eth while you're working on this keep in mind that there are indexes/tocs that will need to be updated for the new names/anchors, and potentially links within other scenarios in the doc too. In order for the PDFs and eBooks to be built and linked successfully the text of the links needs to be the same as the text of the filename (IIRC) [just look around for existing links].

[rbsec]

@kingthorin I'd agree with that - "authenticators" is used is some more formal docs by people like NIST, but doesn't seem to really fit for day-to-day usage.