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

Consider whether phishing protection is possible #90

Open
RByers opened this issue Jan 8, 2025 · 2 comments
Open

Consider whether phishing protection is possible #90

RByers opened this issue Jan 8, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@RByers
Copy link

RByers commented Jan 8, 2025

Problem description
SMS OTP is vulnerable to phishing: where an attacker tricks a user into trying to log in via a fake attacker-controlled website including entering the real SMS OTP code into the attacker-controlled site. The fundamental problem in this attack is that when an SMS OTP is delivered to the user, there is no indication of who that OTP is expected to be provided too and so neither automated systems nor humans can reliably tell whether they are providing their OTP to a legitimate service vs. a hacker-controlled fake.

Possible evolution
Consider encouraging a message format which includes within it a computer-readable identifier for the service which the user is authenticating to, such that any automated systems can detect and silently reject phishing attacks.

For example, the Web OTP specification relies on origin-bound one-time codes to mitigate phishing attacks via SMS OTP.

Alternative solution
Don't rely on SMS for authentication at all.

Additional context
I have not looked much into the details of the CAMARA project so please excuse my ignorance and lack of broader context. But as someone who has worked on authentication on the web as part of the Google Chrome team, I was personally interested in what overlap this proposal may have with the web and browsers. I wanted to just share the context that historically Chrome has previously declined to implement automated support for any SMS-based-authentication systems which are so easily vulnerable to phishing, arguably because they do more to harm security and risk presenting users a false-sense of security given how successful we see phishing attacks are in practice. Web OTP was adopted by Chrome only when phishing-protection was added.

Requiring a specific message format is, of course, a barrier to adoption for systems which do not currently require it, and so Web OTP has seem limited adoption as a result. So I'm certainly not claiming there are any easy answers here. I just wanted to provide context for why, historically, Chrome has been opposed to enabling any SMS OTP-based automation which our security experts felt was inherently insecure.

@RByers RByers added the enhancement New feature or request label Jan 8, 2025
@bigludo7
Copy link
Collaborator

Good topic to be discussed in monthly call.
Probably to late for Spring 25 Camara Release 2 but should be discussed for Release 3.

@HuubAppelboom
Copy link

I would suggest to take a look at Number Verifcation, that will be much harder to be phished (because that uses no OTP)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants