search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.69k stars 657 forks source link

2.2.2 allows email authenticators while NIST 800-63 does not #1046

Closed maizuka closed 2 years ago

maizuka commented 3 years ago

The requirement 2.2.2 says that email is a weak (or restricted) authenticator as well as SMS.

Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods.

However, NIST 800-63B 5.1.3.1 doesn't allow email (and VOIP) as "something you know" authentication.

Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.

And their FAQ page explains that email cannot be communication channel even in MFA. The FAQ page is referred from the two places: V2 and V2.2.

NIST SP 800-63B does not allow the use of email as a channel for single or multi-factor authentication processes.

I'm afraid that this requirement doesn't meet the NIST's guideline and that email should be prohibited for communicating tokens in authentication or password recovery.

Note) In the discussion of issue #559 is related. It is confirmed that SMS to non-VOIP is one of the restricted authenticators but I cannot find how about email.

jmanico commented 3 years ago

This is not accurate per Jim Fenton the SP800-63 lead.

Jim says that authenticators may allow SMS for multi-factor (at AAL level 2) IF another stronger option is available and SMS is not the default option.

maizuka commented 3 years ago

Thank you for information. I have questions.

1) Does Jim say about restriction of SMS only to non-VOIP telephone numbers or even including to VOIP? Sorry but I don't know SMS can be sent to VOIP.

2) Is it the same for email as SMS?

2021年8月22日(日) 0:34 Jim Manico @.***>:

This is not accurate per Jim Fenton the SP800-63 lead.

Jim says that authenticators may allow SMS for multi-factor (at AAL level 2) IF another stronger option is available and SMS is not the default option.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OWASP/ASVS/issues/1046#issuecomment-903133970, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6MXZZGT2BZYKYQL3BCQETT57BQFANCNFSM5CR5GKIQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

jimfenton commented 3 years ago

@maizuka is correct; the restrictions in 5.1.3.1 apply to all out-of-band authenticators, including PSTN (voice and SMS). While SMS is acceptable for use under the guidelines for restricted authenticators, the phone number to which the SMS is delivered must not be a VoIP endpoint, because access to those endpoints doesn't prove possession of a specific physical device. It's possible to determine whether a phone number is a VoIP number using some commercial telephony API services.

Email is not acceptable for out-of-band authentication for the same reason that access to email does not prove possession of a specific physical device.

(Please note that I am a contractor and not a NIST employee so this is not an official statement by NIST).

jmanico commented 3 years ago

Thank you Jim! This is very helpful!

maizuka commented 3 years ago

Thank you for information. It helps me understanding better.

Should we consider updating the requirement 2.2.2, so that email and SMS to a VoIP number are removed from restricted authenticators?

jmanico commented 3 years ago

I instinctively think that is too much detail, but not unreasonably so. So sure, care to submit a PR?

On Sep 11, 2021, at 1:12 AM, IZUKA Masahiro @.***> wrote:

 Thank you for information. It helps me understanding better.

Should we consider updating the requirement 2.2.2, so that email and SMS to a VoIP number are removed from restricted authenticators?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

maizuka commented 3 years ago

@jmanico I have created a PR #1052. The change is based on these understandings.

I guess it needs more changes to adjust the requirement or improve the explanation.

jmanico commented 3 years ago

Your comments below demonstrate a very clear understanding and accurate read of NIST SP800-63. Thank you!

jimfenton commented 3 years ago

If you want to be consistent with SP 800-63B, the RESTRICTED authenticator requirements apply even if it is being used as the second factor at AAL2. It's necessary to offer an alternate physical authenticator, provide meaningful notice to the subscriber, etc.

Of course, if the restricted authenticator is being used to provide additional risk reduction at AAL1 (in addition to a memorized secret), it's not necessary to do this because the memorized secret is sufficient.

Hope this makes it clearer.

cmlh commented 3 years ago

Should we extend this to include https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication too?

jmanico commented 3 years ago

Pardon @maizuka can you kindly give us a new PR based on comments from @jimfenton ?

jimfenton commented 3 years ago

...or just update the current pull request.

By the way, I should remind everyone that I'm not a NIST employee, and my comments aren't an official NIST statement.

cmlh commented 3 years ago

Should I create a new issue for https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication @jmanico or not?

maizuka commented 3 years ago

I will think about AAL2 and Level 2. I don't have idea yet, so welcome if anyone posts suggestion.

And I found a logical failure in the previous change. At AAL1, weak authenticators may be used as secondary verification because the other authenticator (e.g. memorized secrets) makes it sufficient, as well as restricted ones.

ike commented 3 years ago

Perhaps something like the legend that used to be used in the Authentication section V2.1 could help make this distinction? I don't have the historical context for the change that removed this, so it may have been determined to be an anti-pattern.

Mark Description
Not required
o Recommended, but not required
✓ Required

In the requirements, it looked like this:

| 2.8.6 | Verify physical single-factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location. | | ✓ | ✓ | 613 | 5.2.1 | | 2.8.7 | Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know. | | o | ✓ | 308 | 5.2.3 |

ike commented 3 years ago

I found issue https://github.com/OWASP/ASVS/issues/1022 which does talk about the optional notation and the context around removing it. I wonder if there are other ways to convey the graduated optionality of these AAL1 -> AAL2 requirements.

jmanico commented 2 years ago

Let's please keep this discussion to 2.2.2 and open a new issue if you have a comment that is related to another issue. :)

I suggest we change 2.2.2 to the following based on the comments above. I removed the part about secondary authentication and the last sentence. This seems a lot cleaner. cc @maizuka and @jimfenton does this look acceptable?

| 2.2.2 | [MODIFIED] Verify that the weak authenticators (such as VOIP or email) are not used as authentication methods. Verify that the restricted authenticators using PSTN (such as phone or SMS-based OTPs directed to phones) are offered with alternate stronger methods. | ✓ | ✓ | ✓ | 304 | 5.2.10 |

jimfenton commented 2 years ago

My suggestion:

| 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. | ✓ | ✓ | ✓ | 304 | 5.2.10 |

I guess the pull request has been merged, so a new one will be needed. It's helpful to link the pull request to this issue.

jmanico commented 2 years ago

I'll cut a new PR with your suggestion and attach to this shortly. Thank you!

jmanico commented 2 years ago

Any thoughts on this PR, @maizuka ?

jmanico commented 2 years ago

Perhaps something like the legend that used to be used in the Authentication section V2.1 could help make this distinction? I don't have the historical context for the change that removed this, so it may have been determined to be an anti-pattern.

Mark Description

Not required

o Recommended, but not required

✓ Required

In the requirements, it looked like this:

| 2.8.6 | Verify physical single-factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location. | | ✓ | ✓ | 613 | 5.2.1 | | 2.8.7 | Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know. | | o | ✓ | 308 | 5.2.3 |

Can you move this to a new issue or suggestion? I want to briefly resolve the OP's issue here and close it. :)

ike commented 2 years ago

@jmanico -- I totally could, but I think I was misunderstanding the change @maizuka was trying to make. I thought he needed some kind of optionality within each requirement level, which now seems like not the case. I think #1022 has already determined that non-checkmarks are an antipattern in the level requirement box. Long way to say: I'm good leaving this alone if you are?

jmanico commented 2 years ago

😎

maizuka commented 2 years ago

Thank you all. And sorry for late action. I think the new suggestion is ok.

I agree with @jmanico that the sentence about secondary verifications will be removed, because the number of valid authentication factor should be defined in another requirement. (But I couldn't find it for Level2/AAL2. Does it need a new one?)

My another suggestion to try making it clear is below, but this makes it verbose or lack of definition, so not needed.

Verify that weak authenticators (...) are not used as valid authentication methods.

I also agree with @jimfenton's suggestion since the usage of the words will get much clearer.

Comment) I want some longer time of suggestions to be determined, because we live in other time zones and can only work during time in absence of the salary job.

jmanico commented 2 years ago

The initial request in this issue has been solved and merged.