Skip to content

Consider whether phishing protection is possible #90

@RByers

Description

@RByers

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions