6.4.3 / v5.0.be-2.5.6 Verify forgotten password" / MFA issue

[jackgates73]

Hi all,

I'm trying to wrap my head around the requirements around MFA / forgotten password on an application I'm trying to ensure adheres to L2 requirements but services older / less tech savvy users.

• So it is made clear in the document that MFA is optional for apps of this level "Previously, the ASVS has required mandatory MFA. NIST does not require mandatory MFA. Therefore, we have used an optional designation in this chapter to indicate where the ASVS encourages but does not require a control"
• While the ASVS does not mandate the inclusion of a "Forgot Password" feature, if such a feature is implemented, it must adhere to asvs standards. Personally, a method for recovering accounts, whether built into the app or done via a help desk, is a basic service that should be mandatory for any organisation that allows it's customers to create accounts.
• It is clear that any forgotten password process must specifically use MFA "Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism.... Unsafe out of band authenticators such as e-mail and VOIP are not permitted. PSTN and SMS authentication are currently "restricted" by NIST and should be deprecated in favor of push notifications or similar."
• Sure PSTN can be used, but being RESTRICTED and likely to be phased out means that it isn't really an option worth implementing at this point. Therefore it really sounds like MFA is not optional and is a requirement for all apps, L2 and even L3.
• Requiring newer authentication methods like time-based OTP (TOTP), soft tokens, or mobile push notifications in an application primarily serving older, less tech-savvy users for example, presents challenges, and a large portion of our user base would not accept this being mandatory.

Basically the TLDR version is:

• MFA is optional
• Account recovery is required
• Account recovery needs MFA
• Specific types of MFA are required
• These forms of MFA are not accesible to all users of L3/L2 apps

I'm submitting this as a potential issue, although maybe I'm overlooking something, if so it would be good to hear where. Thank you!

[tghosth]

Have you read through the "bleeding edge" version of chapter V2 where we have tried to start clarifying things? Also did you see the discussion in #2457 which is specifically about forgot password?

[jackgates73]

Thanks for linking those resources as I wasn't aware of them but have skimmed through them. So this makes it clear that a second factor authentication is necessary for the forgotten password process only if that user has opted in to do this. But what would a secure forgotten password journey look like for a user that does not opt-in to use MFA just as an example? I looked through the forgotten password cheat sheet and I couldn't see a method that this can be done that doesn't use either a second factor authentication (that isn't 'something you know', excluding sec questions of course which is no longer considered secure), or a side-channel that is still considered secure enough.

[tghosth]

So if you are talking about the fact that the cheatsheet refers to using email as an out of band channel, I'm pretty sure that when NIST says that email is not allowed as an out of band authenticator, it is talking as a primary authentication factor and not as a recovery mechanism. Clearly the use of email as a recover mechanism for a password is pretty universal.

[tghosth]

Also bear in mind that there is an updated NIST draft which is supposed to be clearer in general... https://pages.nist.gov/800-63-4/sp800-63b.html

[jackgates73]

Under the 2.7 summary it says:

"In the past, a common out-of-band authentication mechanism would have been an email or SMS containing a password reset link. Attackers use this weak mechanism to reset accounts they don't yet control, such as taking over a person's email account and re-using any discovered reset links. There are better ways to handle out-of-band verification.....

Unsafe out-of-band authentication mechanisms such as e-mail and VOIP are not permitted. PSTN and SMS authentication are currently "restricted" by NIST and should be deprecated in favor of push notifications or similar. If you need to use telephone or SMS out-of-band authentication, please see NIST SP 800-63B § 5.1.3.3."

So I think it was the talk of email/SMS containing a password reset link being weak, followed shortly by e-mail not being permitted as an out-of-band authentication factor is what led to my confusion here.

I still don't compeltely understand the logic by NIST here though. "when NIST says that email is not allowed as an out of band authenticator, it is talking as a primary authentication factor and not as a recovery mechanism." It sounds like NIST is saying that email tokens are are too weak to be considered primary authentication, but not as a means of resetting the primary authentication. Ideally the reset process has to be just as robust as primary authentication so as to not be used as a bypass.

Appreciate the help with my questions!

[tghosth]

Did you check what the updated NIST draft says about this?

[jackgates73]

Hey, I skimmed through but I couldn't find anything that explicitly explains why one should be allowed and the other disallowed - maybe I missed it?

[tghosth]

Ok, so section 2.7 refers to NIST 5.1.3 but I think that is talking about something slightly different than reset password.

Practically speaking, draft 4 seems to specifically allows credential recovery via various options : https://pages.nist.gov/800-63-4/sp800-63b.html#issued-recovery-codes

[ishowta]

The requirement to use equally strong authentication pathways isn’t required under L1, which I think aligns with the rest of the documents.

(On the other hand, NIST appears to require this requirement for all AALs.)

To satisfy the requirements of a given AAL and be recognized as a subscriber, a claimant SHALL authenticate to an RP or IdP as described in [SP800-63C] with a process whose strength is equal to or greater than the requirements at that level.

#	Description	L1	L2	L3	CWE
1.2.4	[MODIFIED, SPLIT TO 2.2.11] Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which should be consistently enforced across them.		✓	✓	306

However, I do not see the benefit of disallowing email-based authentication when there is already a loophole allowing password resets via email. It might be more practical if L1 also adopted 1.2.4 while allowing passwordless email based single-factor authentication mechanism (e.g., magic links).

#	Description	L1	L2	L3	CWE
2.2.2	[MODIFIED] Verify that email is not used as either a single-factor or multi-factor authentication mechanism.	✓	✓	✓	304

[tghosth]

However, I do not see the benefit of disallowing email-based authentication when there is already a loophole allowing password resets via email.

I think there is a benefit to having a password reset as an exceptional event compare to magic link authentication from an alerting and monitoring perspective.