Suggestion - A little 2fa hint in the login page

[duaneellissd]

Suggestion:

I assume the web page where the 2FA being entered can contain hidden, or meta data of some sort that the human does not see, the web page might for example include a string like this:

2FA-REGEX: AB\d\d\d\d\d\dXY

The idea is: Simply extend the 2FA with a few letters (or digits) to help find the phrase

(a) the browser can know that there is a 2FA activity in process.

For example the web page could have meta data that says: “look for a 2fa message’ as part of its meta data or perhaps in the HTTP header, the regex pattern might be A\d\d\dB\d\d\dC, or maybe A\d\d\d\d\d\d\B

This meta data would be “hidden” to the user otherwise it would be confusing.

B) The user SMS message is thus just a few bytes longer, but - the additional letters serve only as regex anchors that give a more ‘positive’ match.

Result: The user agent has “positive match” pattern that is controlled/specified by the web site, the guessing goes away

C) If/when the human enters the 2FA value, a small amount of javascript on the page could for example perform a simple regex comparison on what the user enters, and then enable the “ok” button - Not much different then some web pages performing a LUHN check on a credit card.

[hober]

I assume the web page where the 2FA being entered can contain hidden, or meta data of some sort that the human does not see

I think there are two pieces of metadata the user doesn't see that we already have in the HTML spec:

• autocomplete=one-time-code marks the field into which a one-time code may be filled,
• and the pattern attribute tells the browser what kinds of values are acceptable for the input element.

I believe these existing HTML features adequately handle the cases you've identified; please let me know if I've missed something.

[mhardeman]

A further concern I have with the proposal regarding format identifiers is that this would require a query-flow from WebKit to the messaging application in which the format to scan for would be passed to the messaging application to facilitate a search for received SMS OTP messages.

If that were actually implemented it would be an obvious target for abuse to try to find and exfiltrate other message content.

[duaneellissd]

I believe your concern is security related, and can occur in either direction.

If we assume that one of the two - browser or sms agent is “reasonably secure” (A) either rate limit requests, or (B) restrict how the match is done.

My suggestion works like this:

There are 3 parties, A - The web browser, B, the SMS agent, and C The authorization system backend.

Each time a request is made, the authorization system generates 2 random sequences. One part is the traditional 2FA, the second part is a MATCH pattern use to help match SMS messages with WEB PAGES.

For the purposes of this discussion I’ll assume the 2FA sequence is 6 digits, for discussion purposes I’ll use 123456 as the sequence.

For discussion purposes, I’ll use the sequence “foobar” - but of course this would be randomized on each request. This “foobar” becomes a shared secrete.

Combining the two, the new 2FA becomes foo123456bar.

The SMS agent gets “The password for your www.bigmoneybank.com is foo123456bar please enter this in your web browser” the HUMAN can view the entire message.

The Browser gets as part of the web page the REGEX that can match exactly 1 word within that message. In this example the REGEX would be: “foo......bar”, but there are restrictions on the REGEX.

To address your concerns (mhardeman) the only query would be via a limited REGEX, For security reasons, the REGEX is highly restricted, in that it must meet these requirements:

1. The regex must start and end with fixed symbols (the match pattern, ie: foobar)
2. The middle, must contain at least 6, at most 10 dots.
3. The middle could optionally contain fixed symbols
4. Normally dot matches anything, but this is special, dot only matches letters and digits.

The BROWSER can thus provide the SMS agent with a match pattern.

I have equal concerns about the SMS agent providing information to the browser that it should not provide.

Thus the regex match pattern does not contain or leak any information about the web site (The current proposal passes a web site name across the divide, this does not pass the web site, and instead uses random letters)

The SMS agent can validate the match pattern (rules above)

There can be other rules, ie: The SMS message age must be less then (X) seconds.

If needed, the SMS agent can rate limit search requests

If needed, the SMS agent can query the user “The browser would like X” do you agree?

The SMS agent then rejects, or accepts the pattern, If a match is found only the matched pattern is returned, nothing else from the message.

What I don’t think is good - is the SMS agent providing information to the browser without some confirmation that the browser is looking for it.

Using this shared secrete model, lets both sides be defensive, with no information leakage.

[hober]

This proposal has been taken up in the @WICG, where you can find an updated explainer as well as a spec. If, after reviewing the spec, you still have concerns on this topic, please file an issue in the spec's dedicated repo.