Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SMS Threat Intel #1696

Closed
cmlh opened this issue Jul 17, 2023 · 3 comments
Closed

SMS Threat Intel #1696

cmlh opened this issue Jul 17, 2023 · 3 comments
Assignees
Labels
1) Discussion ongoing Issue is opened and assigned but no clear proposal yet Community wanted We would like feedback from the community to guide our decision otherwise we will progress Will be closed if no response/opposite arguments _5.0 - Not blocker This issue does not block 5.0 so if it gets addressed then great, if not then fine.

Comments

@cmlh
Copy link
Contributor

cmlh commented Jul 17, 2023

SMS is referenced within ASVS Requirement 2.2.2

@vanderaj considered the residual risk of SMS within #127 (comment)

However @ddz published the following tweet during Summercon 2023:

image

The tweet reproduced as text is "Where @dotmudge makes an important point at @SummerC0n: real data on ATOs shows that SMS 2FA is fine for the vast majority of users. It prevented 100% of 3.3B automated password stuffing attacks, 96% of 12M bulk phishing, and even 76% of <10k targeted attacks seen over last year."

As the purpose of #1495 is to verify the control based on the risk of the application then SMS is fit for purpose according to the available Threat Intelligence. Therefore, should SMS be reconsidered for at least L1?

@tghosth
Copy link
Collaborator

tghosth commented Sep 7, 2023

I went to listen to the talk which is here: https://youtu.be/O0gDd8jXgfY?t=25014

So, my understanding is that mudge is saying that SMS does offer good protection (albeit depending on the scenario). He is not saying we shouldn't advocate for other mechanisms as well. Just because it is good enough for a user, doesn't mean the application should not also offer something stronger.

2.2.2 currently says:

....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.

We are not saying don't use it, we are saying allow stronger methods as well and be clear about the risks. As such, I am comfortable with the current wording.

@tghosth tghosth added 1) Discussion ongoing Issue is opened and assigned but no clear proposal yet Community wanted We would like feedback from the community to guide our decision otherwise we will progress _5.0 - Not blocker This issue does not block 5.0 so if it gets addressed then great, if not then fine. Will be closed if no response/opposite arguments labels Sep 7, 2023
@jmanico
Copy link
Member

jmanico commented Sep 7, 2023

NIST released the Special Publication 800-63B as a guideline for digital identity guidelines which includes three levels of authentication strength. The Authenticator Assurance Levels (AALs) define the strength of the authentication process. There are three levels:

AAL1: Provides some assurance that the claimant controls the authenticator.
AAL2: Provides high confidence that the claimant controls the authenticator.
AAL3: Provides very high confidence that the claimant controls the authenticator.

Relation between SMS MFA and AALs:

AAL1: At this level, SMS-based MFA can be considered acceptable. AAL1 allows for a wide range of authenticators, including weaker ones. However, it's worth noting that even at this level, the use of SMS-based MFA has been criticized due to vulnerabilities like SIM swapping, interception, and social engineering attacks.

AAL2: This level requires at least two distinct authentication factors. While SMS-based MFA could technically be used as one of the factors, NIST 800-63B has expressed reservations about its use. Specifically, the guidelines recommend against the use of out-of-band authentication using the PSTN (public switched telephone network), which includes SMS. The concerns arise from the potential for interception and redirection of SMS messages.

AAL3: At this highest assurance level, the requirements are even stricter. The use of SMS-based MFA would not be recommended or considered secure enough for AAL3 due to the aforementioned vulnerabilities and the potential for sophisticated attacks.

@tghosth
Copy link
Collaborator

tghosth commented Sep 26, 2023

I think our aim is potentially to follow the AAL model so if anyone thinks our current wording does not do so then please open a separate issue so we can reevaluate :)

@tghosth tghosth closed this as not planned Won't fix, can't repro, duplicate, stale Sep 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1) Discussion ongoing Issue is opened and assigned but no clear proposal yet Community wanted We would like feedback from the community to guide our decision otherwise we will progress Will be closed if no response/opposite arguments _5.0 - Not blocker This issue does not block 5.0 so if it gets addressed then great, if not then fine.
Projects
None yet
Development

No branches or pull requests

3 participants