Questions & Comments on the specific phishing mitigation explainer/proposal seeks to achieve

[mhardeman]

Having read the explainer and opened various issues discussing the proposed format for binding a message to an origin, it is clear to me that this format might be helpful in reducing accidental autofill of an OTP value into a page served from a mismatched origin.

However, I do not believe that actually provides meaningful mitigation of SMS OTP code phishing.

I believe that the phishing page will -- if even necessary -- just add language to the input field suggesting "For security reasons, copy-paste is not allowed here." Meanwhile, the user will read the message and key the value in.

Simultaneously, I believe that the format specified for tagging a message as origin bound SMS OTP is insufficiently unique that messaging product owners will be able to rely upon the format for altering the behavior of the messaging app, meaning the user will ultimately be free to read the OTP code and type it in.

To the extent that this will help WebKit not autofill where it should not, I believe the proposed scheme has the potential to succeed in that goal.

With respect to a broader goal of reducing the likelihood of success in phishing of SMS delivered OTP codes from users interacting with the device, I would like to better understand the theory under which it is believed that the proposal will reduce such harms.

[rmondello]

Hi @mhardeman,

I deeply appreciate your skepticism, and the time you’ve taken to write it up. It’s helpful as a check on the concepts and narrative we’ve been building around this proposal.

You wrote:

Having read the explainer and opened various issues discussing the proposed format for binding a message to an origin, it is clear to me that this format might be helpful in reducing accidental autofill of an OTP value into a page served from a mismatched origin.

However, I do not believe that actually provides meaningful mitigation of SMS OTP code phishing.

I appreciate the distinction you’ve been making between accidental disclosure to an incorrect origin, and meaningful phishing protection. You are making an important and thoughtful distinction.

With respect to a broader goal of reducing the likelihood of success in phishing of SMS delivered OTP codes from users interacting with the device, I would like to better understand the theory under which it is believed that the proposal will reduce such harms.

For most of the rest of this reply, I’m going to explain why we believe there’s real value in specifying a format for origin-bound one-time codes in the context of mitigating SMS OTP code phishing.

In any authentication mechanism where a user can make a decision to provide a secret to the wrong party, phishing is not preventable. This is true of SMS OTPs, passwords, and even TOTPs, as implemented today. Nothing categorically prevents a person from making a decision to copy-and-paste or manually type one of these into the wrong context.

That said, passwords have a leg up on the OTP mechanisms that I mention when used in conjunction with a password manager. A password manager makes signing into websites more convenient, but also potentially more secure for users, by training users to think it’s odd when an AutoFill mechanism doesn’t suggest their credential in the context of a sign-in operation. See my comment on issue #8 for some related thoughts.

That is, if I have a credential for site.example saved in my password manager, and visit phishing website imposter.example in my browser, the fact that the site.example credential isn’t suggested by my password manager may give me pause, a possible first step to me realizing I’m on a phishing website. The mechanism and corresponding user guidance are not infallible, but they deliver real value; making secure things easy and insecure things even marginally more difficult provides value.

A similar value applies to origin-bound one-time codes when used with a user agent that respects the origin-bound codes when assisting with providing them to websites. If I’m used to my browser assisting me with providing an ExampleBank code to bank.example, it suddenly not working may give me pause, a possible first step to me realizing I’m on a phishing website.

You may say, and will be right to say, that this type of protection may be too subtle for some people. And there, you’re absolutely right. You even provide an example of a phishing website workaround:

I believe that the phishing page will -- if even necessary -- just add language to the input field suggesting "For security reasons, copy-paste is not allowed here." Meanwhile, the user will read the message and key the value in.

I suspect you’re right that something along these lines will happen. Some people will type their codes, and others will be keyed into something being wrong explicitly by this language, or by the fact that their browser’s otherwise dependable feature doesn’t work on this website. With authentication mechanisms that don’t categorically prevent phishing, mitigations like these are a numbers game — a game of probabilities.

Stopping here, I believe that origin-bound one-time codes provide meaningful value in light of the SMS one-time code phishing problem. However, the existence of origin-bound one-time codes could allow for messaging interfaces to further mitigate the risk of phishing. As discussed in other issues, platform owners could leverage the clarity of a message being about a one-time code, including the website it’s for, to further educate users about properly validating where they’re going to use the code.

Yet again, probabilities. But reducing the odds of a successful phishing attack is worthwhile, especially in light of how widespread SMS 2FA is.

[mhardeman]

I fully concur with all that you state in your response above, @rmondello .

To the extent that I have a dispute, it is in that I believe a small additional change to the proposal could open the door to the messaging side of the equation choosing to make the messages unavailable to the user. The format today isn't specific and unambiguous enough that a messaging application could responsibly choose to decline the user access to the message, save for via the auto-fill route. A special string akin to a mime-type in the format might very well change that calculus. In such a scheme, both the goals that you've stated are achieved and a stretch goal of further reducing opportunities for phishing are achieved.

Without question, I already concede and put forth that the proposal as it stands is an improvement over the status quo. I believe it will give you a strong case that "WebKit worked to not make phishing SMS OTP codes worse." But would it not be better if the proposal left room to enable an effective reduction in phishing overall?

[hober]

To the extent that I have a dispute, it is in that I believe a small additional change to the proposal could open the door to the messaging side of the equation choosing to make the messages unavailable to the user.

I don't believe any change is necessary to enable platforms to make such an implementation choice because I disagree with this assertion:

The format today isn't specific and unambiguous enough that a messaging application could responsibly choose to decline the user access to the message, save for via the auto-fill route.

[mhardeman]

@hober,

Understood and accepted, with polite dissent.

[hober]

@hober,

Understood and accepted, with polite dissent.

That's fair. I haven't shown my work yet, by writing the parser spec. I'll message you when I do, so you can review & see if it alleviates your concern here.

Thanks for all your thoughts on this!