New tags for TOTP and U2F?

[Carlgo11]

Hello, we've seen several people of the past year requesting a way to check if a site supports TOTP(RFC #6238)(commonly referred to as Google Authenticatior) or if they require proprietary 2FA software. We've also seen quite a few people requesting a distinction between U2F hardware and other hardware factors.

There are several ways we could implement this.

1.

Use the existing software and hardware tags to specify this. Such as software: TOTP for TOTP authentication and keeping the software: Yes for non-TOTP software. The advantage here is that old contributions don't need to be changed for this to work and so the sites supporting TOTP could over time have their status updated. Furthermore it would keep the length of the YAML files as they are right now.

A disadvantage here is that our current way of allowing third parties to access our data (via data.json) would require them to update their fetching of the data or it could potentially break them.

As of right now there are very few third parties using our data and so making them all implement the changes would probably not be very hard. For the future however we would need some sort of versioning system of the data.json to eliminate this risk.

2.

Building on the existing software and hardware tags, we could do like with the exception tag and make it an array. That could allow for a more future-proof setup with multiple choices. The downside here is that it would require lots more work as the code need to be changed to allow for an array and all existing sites listed here that use the software or hardware tags would need to be changed.

3.

Another way is to simply add a totp and u2f tag to the YAML parsing. This would mean less work for the third parties but larger file sizes for us.

Technically speaking, how much work would this mean? (pinging @psgs for UI and @stephengroat for Travis-CI/script changes) I think the best approach would be to first implement this in data.json and then do the UI changes. That way there's fewer ways the change could go wrong.

I'd love to hear some feedback from @2factorauth/collaborators along with any third party maintainers (@conorgil @jadchaar)

[jadchaar]

It shouldn't be too hard to adjust parsing scripts to the new data format. As long as the changes are beneficial and add useful data points, it will be well worth it.

One thing I wanted to mention is that if you guys decide to go for the array approach for software and hardware tags, you should add a duo option (e.g. support Duo push). Also, since I see that SendGrid uses Authy 7 digit codes, it may be useful to have an authy option as well.

[jadchaar]

Also, wouldn't it be better to put a proprietary option under software rather than totp? The reason I say that is because what if a service, for example Apple, uses TOTP behind the scenes, but just does not allow someone to scan a QR code and use the client secret in a third party app? That is technically TOTP, but it uses a proprietary implementation.

[conorgil]

Thanks for pinging me so I got an email about this convo. I'm catching up on email after the holiday weekend here in the US and just wanted to let you know that this is on my TODO list to read this and reply with more thoughts. I will get to it this week.

[Carlgo11]

@jadchaar any other synonyms to proprietary that we could use? I think that using "proprietary" would mean a lot of misspellings.

[RichJeanes]

I like option 2, but being a breaking change does worry me a little. Perhaps start the changes on a separate branch and post a heads up that we are going to be making a breaking change and give a date for when the changes will go live? Give the third-parties using our data a month or two to accommodate the changes?

If we define a set of valid tags, we could keep the basic Yes option so that we don't have to update EVERY site right out of the gate. If there are any valid values listed, the site would still display the check mark and anything other than Yes could be listed in a tool tip on the check mark (either a standard browser tool tip or as a schmancy one lie for the exceptions). This keeps the look of the site clean and simple for basic users while still exposing that info on the site for advanced users and for any third-parties who want to make use of it from the JSON. (Or allow for free form text to be displayed in the tool tip, but that could get real messy real fast.)

Examples: software: Yes software: TOTP Proprietary Authy hardware: Yes hardware: Paper U2F

@mxxcon

[jadchaar]

@Carlgo11 sorry I missed your ping and just saw your message. I am unsure how else to describe an implementation forcing something like authy other than using the word proprietary. I feel like that covers a general case rather than having specific tags dedicated to "authy", "duo", etc.

[mxxcon]

We also have an option of keeping data.json as is for the existing implementations and instead create data_v2.json which is more expanded. This way external users could switch to the new format if they will find it useful and at their own pace.

[RichJeanes]

@mxxcon So when we generated the data.json, it would convert something like software: TOTP to software: Yes and leave Nos as Nos?

[Carlgo11]

@mxxcon that would mean we’d have to completely rewrite data.json as it as of right now would display software: TOTP as software: “TOTP”. It’s just set to output all the tags along with its data.

[hsivonen]

Now that both Firefox and Chrome support FIDO U2F (CTAP1) tokens via WebAuthn, but most sites that support these tokens support them only via Chrome's non-standard legacy API, it's pretty frustrating to search the list as a Firefox user.

It would be useful to be able to see at a glance, which sites support FIDO U2F (CTAP1) tokens via the cross-browser standard WebAuthn API. (Notably, Dropbox supports these tokens via WebAuthn today. The rest of the sites listed as "Hardware", generally not.)

[Carlgo11]

@hsivonen I think that's out of the scope of this project. It would also be very very hard for us to check what API they use.

[Carlgo11]

Update: Another way of inserting the data in the YAML could be to use a tag inside the exceptions array. Like:

- Example.com
  url: http://example.com
  tfa: Yes
  exceptions:
    proprietary: Yes

That wouldn't break third party services and could probably be implemented on the site rather easily.

@RichJeanes listing the available services in a single line alongside the "Proprietary" data would mean we can't check the spelling of Proprietary via Travis-CI. Unless we treat software tags that don't contain TOTP/Yes as being proprietary however that would have the same problems as solution 1. 🤔

[nelsonjchen]

Facebook seems to support both. I think I need a confirmation but the proprietary mobile app has a code generator in it and it can do the non-proprietary TOTP thing too.

[Carlgo11]

@nelsonjchen that’s correct but this issue isn’t about any specific site’s 2FA status but about our UI and data management.

[nelsonjchen]

Of course. I'm just mentioning that there exists a site that has both a proprietary and non-proprietary offering. In the resulting UI for Facebook's entry, it shouldn't imply that proprietary is the only way to go and that there is also a non-proprietary option as well. I wouldn't be surprised if a few other sites do this too with their own apps.

[Carlgo11]

Fixed in #4090