You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: