[Question] Does V2.2.2 allow magic links?

[thomasdax98]

I have a question regarding requirement 2.2.2. Here it says:

Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval [...]

Does this mean that authentication via magic link is prohibited?

If so, why is it prohibited?
Most applications allow resetting a password via email. So if an attacker gains access to an email account, they can simply reset the password.
Therefore, SFA via magic link doesn't seem more vulnerable to me than SFA via password.

[tghosth]

Yes I think this currently forbids magic links. However, looking back at the linked section of NIST, I am not convinced this was the original purpose.

To me, this NIST section is saying that you shouldn't use this sort of authentication method without also offering a stronger methods which is slightly different to what we are saying here.

The only relevant part of NIST I could find which specifically mentions email is 5.1.3.1 which is talking about "out of band authenticators" which is something else.

In summary, @elarlang @jmanico @danielcuthbert I think we should re-word this requirement to focus on only offering weak authentication (like magic links) if stronger authentication is also offered and the risks of the weak method are made clear.

We could also consider checking whether we mention email in the context of out of band authenticators anywhere and if not whether we should add it.

Any other thoughts?

[danielcuthbert]

I wouldn't call magic links weak, I mean I use them a lot and when done properly, they offer a good balance between frictionless security and device checking (when done properly), but I do agree that this one needs a rethink around the wording.

[tghosth]

@wet-certitude do you have any thoughts on this based on what you said in #1397?

[tghosth]

@wet-certitude any final thoughts?

[maizuka]

As refactored to 2.2.2 for v5, NIST says the RESTRICTED authenticators can be used when stronger methods are offered.
But email is not categorized as RESTRICTED.
FYI.

[tghosth]

I think the first sentence of this requirement is not really relevant, I have opened PR #1446 for any further comment. I will finalize it for merging in if no one has commented further in 2 weeks.

[maizuka]

The quoted sentence at the top of this issue is old and it has been reworded after discussion in the issue #1046.

Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval [...]
-> Verify that weak authenticators (such as out-of-band authentication using VOIP or email) are not used as authentication methods. [...]

I've read the pull request #1446 that removes this description about weak authenticators. Could you tell me whether email authentication is allowed again?

[tghosth]

Thanks for pointing our that previous issue @maizuka, I need to look into this further and the PR might change again...

Sorry for the confusion

@set-reminder 1 week @tghosth to look at this

[octo-reminder]

⏰ Reminder
Wednesday, January 4, 2023 12:00 AM (GMT+01:00)

@tghosth to look at this

[tghosth]

Ok, I have had a careful read through this issue, issue #1046 and the NIST guidance.

ASVS 2.2.2 is referring specifically to restricted authenticators which does not include email so I think it is correct that 2.2.2 does not mention email.

However, NIST has clearly mentioned in multiple places that it considers email an unacceptable authenticator factors but we don't seem to have a requirement that specifically mandates that and I think one needs to be added.

Verify that email is not used as either a single-factor or multi-factor authentication mechanism.

I update PR #1499 accordingly.

[tghosth]

@set-reminder 3 days @tghosth to open a PR

[octo-reminder]

⏰ Reminder
Sunday, January 8, 2023 12:00 AM (GMT+01:00)

@tghosth to open a PR

[maizuka]

Thank you for the comment.

The 2.2.2 is a requirement for both weak (forbidden) authenticators and restricted ones.
I think it is possible to divide to two requirements, but maybe too small to specify about authenticators.

Or, we can list allowed authentication methods like NIST instead of listing forbidden methods. However, it would be less pratical because there are methods that we don't use commonly.

Addition to email, VoIP is also forbidden in NIST so I think it should be mensioned if we will create new requirement.

I'd like to know why the requirement about "weak" should be deleted or divided. Again, the original question is about the old v4.0 requirement.

---

Current 2.2.2

[MODIFIED] Verify that weak authenticators (such as out-of-band authentication using VOIP or email) are not used as authentication methods. Verify that restricted authenticators (those using PSTN to deliver OTPs via phone or SMS) are offered only when alternate stronger methods are also offered and when the service provides information on their security risks to users.

[octo-reminder]

🔔 @tghosth

@tghosth to open a PR

[tghosth]

Hi @maizuka,

In my opinion, 2.2.2 has confused three issues. "Restricted" authenticators, "out of band" authenticators and "unacceptable"/"forbidden" authenticators.

"Restricted" authenticators

"Restricted" authenticators have specific requirements which are noted in 2.2.2 and in 5.2.10 of NIST.

This is what 2.2.2 is primarily talking about so it makes sense it stays.

"Out of band" authenticators

"Out of band" authenticators is a specific definition discussed in 5.1.3.1 but which ASVS explicitly does not handle as noted here:

The ASVS assumes that only a few developers will be developing new out of band authenticators, such as push notifications, and thus the following ASVS controls apply to verifiers (Josh note: "Out-of-Band Verifiers" are something else and are discussed in 5.1.3.2), such as authentication API, applications, and single sign-on implementations. If developing a new out of band authenticator, please refer to NIST SP 800-63B § 5.1.3.1.

As such it is not appropriate that this is mentioned in 2.2.2 because it is explicitly excluded from ASVS.

"unacceptable"/"forbidden" authenticators.

With the greatest respect to NIST, it is possible I missed it but I don't see a good place in the body of NIST SP 800-63B which explains that they consider email to be unacceptable for any sort of authentication. However, in the FAQ they clearly and unequivocally state this:

Q-B11:
Is the use of email acceptable in two-factor authentication?

A-B11:
NIST SP 800-63B does not allow the use of email as a channel for single or multi-factor authentication processes... (Josh note: it then goes on to point to the "Out of band" authenticators section despite this section being a lot more specific than what they just included in the FAQ...)

As such, I think we also need a clear requirement around this for 5.0 but that it should be separate to 2.2.2 which is talking about restricted authenticators. (Note that we are not going back and making changes to 4.x at this point).

What do you think?

I have updated #1499 accordingly

[maizuka]

Hi @tghosth,

I understand that you think that the main point of 2.2.2 is restricted authenticators. But I wrote this modified requirement to specify what authenticators are completely unacceptable or partly acceptable (restricted). It might be ok to separate in order to clarify the necessary condition to use the latter.

I disagree that out-of-band authenticators are excluded in ASVS, because the description is only about new developed ones. Commonly used authenticators should be in scope.

And you told that SP800-63B doesn't call email as unacceptable, but this document say that non-listed authenticators are unacceptable in AAL1. So email is unacceptable because it isn't defined anywhere.

4.1.1 Permitted Authenticator Types
AAL1 authentication SHALL occur by the use of any of the following authenticator types, which are defined in Section 5:

This can be said also for VoIP, which is described together with email. Do you intend to reduce it?

[tghosth]

I disagree that out-of-band authenticators are excluded in ASVS, because the description is only about new developed ones. Commonly used authenticators should be in scope.

As I said here #1394 (comment), ASVS 4.x explicitly says that it does not provide requirements for "out-of-band authenticators". Whether that is a a correct approach or not is a different question :)

The difference between email and VoIP is that NIST describes VoIP as just not being allowed for "out-of-band authenticators" (for the specific reason that if you use VoIP as a second factor then it is likely that you are just relying on a second password rather than a physical device) whereas for email it seems to specifically call it out as being unacceptable for all uses, single or multi factor.

If we add requirements on "out-of-band authenticators" then we should probably mention VoIP but at this point we don't have requirements on this. Do you propose that we add them?

[maizuka]

My understanding for the paragraph is that a "new" developed out-of-band authenticator is out of scope and existing one is not.
Do you mean that only verifiers should be in-scope while authenticators not?
In addition, email, VoIP and PSTN authenticators are described in the next paragraph, so ASVS have them.

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. If you need to use telephone or SMS out of band authentication, please see NIST SP 800-63B § 5.1.3.3.

The NIST article is new for me.
It is sure that VoIP has a factor "something you know" rather than "something you have" as well as email, but because it is not listed in the Permitted Authenticator Types in SP800-63B, it should be not permitted for single or multi factor.

I don't propose new requirements but propose to just keep it.
The top of this thread is question if magic links are allowed, and I can't find where discussion to separate the requirement or to remove VoIP is taken.

---

To make it clear, I copy the current change from #1499:

Original

2.2.2 [MODIFIED] Verify that weak authenticators (such as out-of-band authentication using VOIP or email) are not used as authentication methods. Verify that restricted authenticators (those using PSTN to deliver OTPs via phone or SMS) are offered only when alternate stronger methods are also offered and when the service provides information on their security risks to users.

Your Proposal

2.2.2 [MODIFIED, SPLIT TO 2.2.12] Verify that restricted authenticators (those using PSTN to deliver OTPs via phone or SMS) are offered only when alternate stronger methods are also offered and when the service provides information on their security risks to users.
2.2.12 [ADDED, SPLIT FROM 2.2.2] Verify that email is not used as either a single-factor or multi-factor authentication mechanism.

[tghosth]

So @maizuka let's assume that I want to split 2.2.2 because it is talking about two different things, how would you word the split requirements?

[maizuka]

I would split the requirement by each sentence. Because 4.x uses the word "weak authenticators" at 2.2.2, I would keep the number for "weak" and assign new for "restricted".

For CWE mapping, original is mapped to CWE-304 "Missing Critical Step in Authentication", but CWE-1390 "Weak Authentication", found in your proposal, seems to be better.

For NIST mapping, 5.2.10 has just the name "Restricted Authenticators". There is no section naming "Weak Authenticators". The 4.5 "Summary of Requirements" has an useful table with authenticator types for each AAL, but since it is informative section, it may be not good to map.

That is, my draft would be, based on your one:

| 2.2.2 | [MODIFIED, SPLIT TO 2.2.12] Verify that weak authenticators (such as out-of-band authentication using VOIP or email) are not used as authentication methods. | ✓ | ✓ | ✓ | 1390 | |
| 2.2.12 | [ADDED, SPLIT FROM 2.2.2] Verify that restricted authenticators (those using PSTN to deliver OTPs via phone or SMS) are offered only when alternate stronger methods are also offered and when the service provides information on their security risks to users. | ✓ | ✓ | ✓ | 1390 | 5.2.10 |

[tghosth]

Sorry for the delay in response.

It looks like we agree about the restricted authenticators part of the requirement but not the part about email/weak authenticators.

Verify that weak authenticators (such as out-of-band authentication using VOIP or email) are not used as authentication methods.

From my perspective this sentence is not really usable or understandable and in any case it uses the expressions "weak authenticators" and "out of band authenticators" which are only used by NIST in a single context which as I said in this comment the ASVS explicitly does not handle.

As such, I stand by my proposed change in #1499 and don't see any compelling arguments to keep the current confusing wording.

[tghosth]

No responses so i am going to send the PR for approval.

[elarlang]

[ADDED, SPLIT FROM 2.2.2] Verify that email is not used as either a single-factor or multi-factor authentication mechanism.

What means "email is not used"? Sending some code or link to email?

[tghosth]

[ADDED, SPLIT FROM 2.2.2] Verify that email is not used as either a single-factor or multi-factor authentication mechanism.

What means "email is not used"? Sending some code or link to email?

Ask NIST 🤣 https://pages.nist.gov/800-63-FAQ/#q-b11

[maizuka]

Sorry for too delayed response. I agree with @tghosth to stop using the ambiguous words "weak" and "out-of-band".

The only question that remains is where the sentense about VOIP authentication is going, but it can be implicitly derived from the requirement on the PSTN authentication.
So I have no longer objections for the PR. Thank you for your patient effort!

[tghosth]

Thanks @maizuka!

@elarlang can we rebase/merge the PR now?