7 ms·

Google Chrome U2F API decommission: What the change means

112 points by vmoore 5y ago

dathinab 5y ago
Oh god, that scared me for a moment until I realized what's going on ...
tazjin 5y ago
This is the first I'm hearing of this change, and considering that this is likely true for many people the migration timeline seems awfully short.
- devrand 5y ago
  If you're using the U2F API you've been getting a warning about it since November. I can't imagine developers that are using it are still unaware at this point, particularly when it's a user-facing warning and not just buried in the developer tools.
  - qudat 5y ago
    3 months is not a long time at all.
    - xxpor 5y ago
      It's not, but as someone who has to deal with multi-year depreciations, setting the expectation that 3/4 month depreciations are something you'll have to deal with, is probably healthier for the ecosystem as a whole. It sets up positive incentives around automating testing and deployments. Anything that's valuable enough that you'd use u2f to auth to needs to be in this mode for general security updates regardless. Granted, moving to a new API is almost certainly more work than a normal security upgrade, but the point is that these types of websites are not something that you can set and forget. They need dedicated, ongoing maintenance.
    - paddez 5y ago
      Especially not across the Holiday period.
    - devrand 5y ago
      It's three months to become aware of the problem, and maybe migrate. If you cannot complete the migration in the window you can opt into the deprecation trial and you'll have until around August.
- dathinab 5y ago
  The migration period since warnings is afully short (~3 month, over Christmas and new year too). But as far as I understand you where supposed to start mitigating since WebAuthn was ready. Not sure when that was but it was quite a while ago.
  - devrand 5y ago
    It's three months from notification until it's disabled by default. You can opt into the deprecation trial and you'll have until early August to migrate.
  - tssva 5y ago
    The deprecation and accompanying warning was in November but Google publicly stated their intention to deprecate in November and remove at the end of February at least as far back as June. Edit: The intent to deprecate and remove was sent to the blink-dev mailing list on June 11th. It can be found on row 2731 of the Blink Intents spreadsheet, https://bit.ly/blinkintents https://bit.ly/blinkintents.
- jtcasper 5y ago
  I think we found out about it in October or November from a pre-release Chromium Edge user? I definitely was surprised to see as short a turnaround as 5-6 months, and if you're only hearing about it now I can't imagine the stress. I was lucky to have some time to work on it and get it done before the holidays so I didn't have to worry too much. I wrote up a migration blog post and commented it here as well because I know I wanted that kind of resource when I was working on it, so if anyone needs that I hope it helps.
- kccqzy 5y ago
  I have been hearing about this for a few months now since logging in to Vanguard (the brokerage) throws a Chrome warning about using the deprecated API. I don't think Vanguard has migrated yet.
qudat 5y ago
We just migrated our web service from u2f api to webauthn and it was a massive pain. It’s true the old keys worked but it relies on using an extensions api within webauthn. Even without backwards compatibility, there are a lot of pieces that have to be set properly and rely heavily on third-party libraries to be written correctly for things to work. I get the security benefits over something like OTP but it is vastly simpler to setup. Getting an RP ID to work across multiple subdomains, legacy trusted facets, origin checks, proper marshaling and unmarshaling of binary / base64 / base64 url safe are real pain points. Things will work with localhost but then when you deploy it doesn’t with the real domains / subdomains / origin / rp id. Not fun and the documentation is at times rather vague. For example, what is a registrable domain? I spent hours and hours trying to figure this out by reading the specification. I don’t know why but no matter what I tried I couldn’t get webauthn to recognize ngrok.io as one so things would fail. Probably my misinterpretation but still frustrating nonetheless. We also have a cli counterpart and libfido2 has virtually no documentation so I’m traversing C code to figure out vague error messages like “err invalid length.”
- psanford 5y ago
  Adam Langley's blog about webauthn is still the best resource that explains how everything fits together: https://www.imperialviolet.org/2018/03/27/webauthn.html https://www.imperialviolet.org/2018/03/27/webauthn.html
- paulryanrogers 5y ago
  IIRC the only reliable way to check if a domain is registrable is to rely on a public suffix list. ICANN's TLD binge has made keeping those PSLs up to date a challenge.
- tialaramex 5y ago
  From your description it sounds like you were fighting very hard to make this into a box ticking exercise which didn't deliver any security, and unsurprisingly WebAuthn wasn't interested in helping you achieve that. I found it very easy to deploy WebAuthn securely, writing everything from scratch as a toy project to understand how it works, but of course I wasn't fighting to mark the checkbox while not delivering security. > what is a registrable domain? [...] I couldn't get webauthn to recognize ngrok.io A registrable domain is a domain that "you" aren't sharing with somebody else. For example this site is sharing .com with millions of other separate entities, so WebAuthn is not interested in having credentials for "com" because that wouldn't mean anything and introduces needless privacy risk, but Y Combinator owns all of ycombinator.com so that would constitute a registrable domain. ngrok.io as you presumably knew but omitted to mention, is used by large numbers of different entities to build network tunnels, so it doesn't mean anything to have "ngrok.io" credentials any more than for "com" and WebAuthn won't allow that. For now, for want of anything better, the PSL is used in browsers to figure out what counts and what doesn't, but the rule of thumb I described above will serve you very well.
alopes 5y ago
As a YubiKey user, is this something I need to worry about?
- dathinab 5y ago
  Most likely not. There had been a U2F API which later on had been superseded by WebAuthn (which internally uses the U2F protocol) and which is now shut down. There is a good chance all your services are using WebAuthn. I'm not sure but I think Firefox never supported the API which is now deprecated.
- psanford 5y ago
  No. Webauthn is backwards compatible with old u2f tokens, so reguardless of how old your YubiKey is, it will continue to work.
- jackson1442 5y ago
  Only site I use that uses U2F (and I enroll my keys everywhere I can) is Vanguard; every other site I use supports WebAuthn.
captn3m0 5y ago
Atlassian is the only site where I’ve gotten warnings about the old API being used.
- demianr 5y ago
  Salesforce is another one.
psanford 5y ago
A few things to note because this can be confusing. Old u2f tokens are still supported by webauthn. The change here is specifically about what javascript APIs are available to websites. If you are wondering if a site is using the webauthn or u2f api: the webauthn flow involves the browser showing a modal dialog. The u2f flow allowed for javascript to interact with your token without the browser itself showing a dialog. You can see what the webauthn flow is with one of the many test sites, like https://webauthn.io/ https://webauthn.io/
- psanford 5y ago
  If you're curious why it has taken Google accounts so long to switch over to webauthn, there was a fairly interesting discussion about this on the mozilla-dev mailing list back in 2019[0]. The tldr is: some Android OEMs baked U2F into their OS images that were then never updated. Switching to webauthn could have effectively locked users out of these devices. [0]: https://groups.google.com/g/mozilla.dev.platform/c/q5cj38hGTEA/m/lC834665BQAJ https://groups.google.com/g/mozilla.dev.platform/c/q5cj38hGT...
  - j16sdiz 5y ago
    It is kind of unrealistic to read every maillist your work depends on.. Many people don't know about this until the deprecation note appears on his desktop.
    - psanford 5y ago
      This mailing list post has nothing to do with the u2f api being deprecated in chrome. Edit: correct which api is deprecated.
  - riedel 5y ago
    I always thought that standards are there to be stable and well documented. This whole fido mess shows how IMHO it should not be done. Anyone who e.g. build stuff on top of CTAP on windows saw their stuff break because windows proxies the whole webauthn stuff through their windows hello APIs and made sure that USB access to FIDO devices is blocked on OS level. What is left is a totally underdocumented webauthn.h header file from Microsoft on GitHub. I am confident that they will break things over and over again, so that it best fits them.
zinekeller 5y ago
Very unrelated: why does the favourite stock photo for "Google Chrome" is a 2014-era Firefox on a Windows 7 computer displaying the Chrome download webpage? I'm not just talking about this particular post, but rather it seems that there's no incentive for stock photo companies to commission an update.
jtcasper 5y ago
I just migrated our auth service for my employer and wrote up a guide on what I think you need to know and should do if you're going through it. I think it was overall incredibly straightforward, and the Yubico maintainers even added some additional functionality to their Java server-side library as I corresponded with them. To plug myself a bit, hopefully this can be helpful to others, and I'd appreciate feedback if you find it unclear: https://www.jacobcasper.com/u2f2webauthn.html https://www.jacobcasper.com/u2f2webauthn.html
ferdowsi 5y ago
The blog post is misconstruing things; WebAuthn is not totally backwards compatible with U2F. Specifically, WebAuthn doesn't support the U2F trusted facets functionality, which allowed for a U2F credential to be used on a cross-origin basis. https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-appid-and-facets-v1.2-ps-20170411.html https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid...
- tialaramex 5y ago
  Is anybody actually doing that? To me it looks like something that's astoundingly fragile and unwieldy and I'd expect that most "users" of this feature were either opening themselves up to a vulnerability they hadn't considered or were in fact attackers targeting such a vulnerability. Yuck.

112 points by vmoore 5y ago

Oh god, that scared me for a moment until I realized what's going on ...

This is the first I'm hearing of this change, and considering that this is likely true for many people the migration timeline seems awfully short.

devrand 5y ago
If you're using the U2F API you've been getting a warning about it since November. I can't imagine developers that are using it are still unaware at this point, particularly when it's a user-facing warning and not just buried in the developer tools.
- qudat 5y ago
  3 months is not a long time at all.
  - xxpor 5y ago
    It's not, but as someone who has to deal with multi-year depreciations, setting the expectation that 3/4 month depreciations are something you'll have to deal with, is probably healthier for the ecosystem as a whole. It sets up positive incentives around automating testing and deployments. Anything that's valuable enough that you'd use u2f to auth to needs to be in this mode for general security updates regardless. Granted, moving to a new API is almost certainly more work than a normal security upgrade, but the point is that these types of websites are not something that you can set and forget. They need dedicated, ongoing maintenance.
  - paddez 5y ago
    Especially not across the Holiday period.
  - devrand 5y ago
    It's three months to become aware of the problem, and maybe migrate. If you cannot complete the migration in the window you can opt into the deprecation trial and you'll have until around August.
dathinab 5y ago
The migration period since warnings is afully short (~3 month, over Christmas and new year too). But as far as I understand you where supposed to start mitigating since WebAuthn was ready. Not sure when that was but it was quite a while ago.
- devrand 5y ago
  It's three months from notification until it's disabled by default. You can opt into the deprecation trial and you'll have until early August to migrate.
- tssva 5y ago
  The deprecation and accompanying warning was in November but Google publicly stated their intention to deprecate in November and remove at the end of February at least as far back as June. Edit: The intent to deprecate and remove was sent to the blink-dev mailing list on June 11th. It can be found on row 2731 of the Blink Intents spreadsheet, https://bit.ly/blinkintents https://bit.ly/blinkintents.
jtcasper 5y ago
I think we found out about it in October or November from a pre-release Chromium Edge user? I definitely was surprised to see as short a turnaround as 5-6 months, and if you're only hearing about it now I can't imagine the stress. I was lucky to have some time to work on it and get it done before the holidays so I didn't have to worry too much. I wrote up a migration blog post and commented it here as well because I know I wanted that kind of resource when I was working on it, so if anyone needs that I hope it helps.
kccqzy 5y ago
I have been hearing about this for a few months now since logging in to Vanguard (the brokerage) throws a Chrome warning about using the deprecated API. I don't think Vanguard has migrated yet.

qudat 5y ago

We just migrated our web service from u2f api to webauthn and it was a massive pain. It’s true the old keys worked but it relies on using an extensions api within webauthn. Even without backwards compatibility, there are a lot of pieces that have to be set properly and rely heavily on third-party libraries to be written correctly for things to work. I get the security benefits over something like OTP but it is vastly simpler to setup. Getting an RP ID to work across multiple subdomains, legacy trusted facets, origin checks, proper marshaling and unmarshaling of binary / base64 / base64 url safe are real pain points. Things will work with localhost but then when you deploy it doesn’t with the real domains / subdomains / origin / rp id. Not fun and the documentation is at times rather vague. For example, what is a registrable domain? I spent hours and hours trying to figure this out by reading the specification. I don’t know why but no matter what I tried I couldn’t get webauthn to recognize ngrok.io as one so things would fail. Probably my misinterpretation but still frustrating nonetheless. We also have a cli counterpart and libfido2 has virtually no documentation so I’m traversing C code to figure out vague error messages like “err invalid length.”

psanford 5y ago
Adam Langley's blog about webauthn is still the best resource that explains how everything fits together: https://www.imperialviolet.org/2018/03/27/webauthn.html https://www.imperialviolet.org/2018/03/27/webauthn.html
paulryanrogers 5y ago
IIRC the only reliable way to check if a domain is registrable is to rely on a public suffix list. ICANN's TLD binge has made keeping those PSLs up to date a challenge.
tialaramex 5y ago
From your description it sounds like you were fighting very hard to make this into a box ticking exercise which didn't deliver any security, and unsurprisingly WebAuthn wasn't interested in helping you achieve that. I found it very easy to deploy WebAuthn securely, writing everything from scratch as a toy project to understand how it works, but of course I wasn't fighting to mark the checkbox while not delivering security. > what is a registrable domain? [...] I couldn't get webauthn to recognize ngrok.io A registrable domain is a domain that "you" aren't sharing with somebody else. For example this site is sharing .com with millions of other separate entities, so WebAuthn is not interested in having credentials for "com" because that wouldn't mean anything and introduces needless privacy risk, but Y Combinator owns all of ycombinator.com so that would constitute a registrable domain. ngrok.io as you presumably knew but omitted to mention, is used by large numbers of different entities to build network tunnels, so it doesn't mean anything to have "ngrok.io" credentials any more than for "com" and WebAuthn won't allow that. For now, for want of anything better, the PSL is used in browsers to figure out what counts and what doesn't, but the rule of thumb I described above will serve you very well.

alopes 5y ago

As a YubiKey user, is this something I need to worry about?

dathinab 5y ago
Most likely not. There had been a U2F API which later on had been superseded by WebAuthn (which internally uses the U2F protocol) and which is now shut down. There is a good chance all your services are using WebAuthn. I'm not sure but I think Firefox never supported the API which is now deprecated.
psanford 5y ago
No. Webauthn is backwards compatible with old u2f tokens, so reguardless of how old your YubiKey is, it will continue to work.
jackson1442 5y ago
Only site I use that uses U2F (and I enroll my keys everywhere I can) is Vanguard; every other site I use supports WebAuthn.

captn3m0 5y ago

Atlassian is the only site where I’ve gotten warnings about the old API being used.

demianr 5y ago
Salesforce is another one.

psanford 5y ago

A few things to note because this can be confusing. Old u2f tokens are still supported by webauthn. The change here is specifically about what javascript APIs are available to websites. If you are wondering if a site is using the webauthn or u2f api: the webauthn flow involves the browser showing a modal dialog. The u2f flow allowed for javascript to interact with your token without the browser itself showing a dialog. You can see what the webauthn flow is with one of the many test sites, like https://webauthn.io/ https://webauthn.io/

psanford 5y ago
If you're curious why it has taken Google accounts so long to switch over to webauthn, there was a fairly interesting discussion about this on the mozilla-dev mailing list back in 2019[0]. The tldr is: some Android OEMs baked U2F into their OS images that were then never updated. Switching to webauthn could have effectively locked users out of these devices. [0]: https://groups.google.com/g/mozilla.dev.platform/c/q5cj38hGTEA/m/lC834665BQAJ https://groups.google.com/g/mozilla.dev.platform/c/q5cj38hGT...
- j16sdiz 5y ago
  It is kind of unrealistic to read every maillist your work depends on.. Many people don't know about this until the deprecation note appears on his desktop.
  - psanford 5y ago
    This mailing list post has nothing to do with the u2f api being deprecated in chrome. Edit: correct which api is deprecated.
- riedel 5y ago
  I always thought that standards are there to be stable and well documented. This whole fido mess shows how IMHO it should not be done. Anyone who e.g. build stuff on top of CTAP on windows saw their stuff break because windows proxies the whole webauthn stuff through their windows hello APIs and made sure that USB access to FIDO devices is blocked on OS level. What is left is a totally underdocumented webauthn.h header file from Microsoft on GitHub. I am confident that they will break things over and over again, so that it best fits them.

zinekeller 5y ago

Very unrelated: why does the favourite stock photo for "Google Chrome" is a 2014-era Firefox on a Windows 7 computer displaying the Chrome download webpage? I'm not just talking about this particular post, but rather it seems that there's no incentive for stock photo companies to commission an update.

jtcasper 5y ago

I just migrated our auth service for my employer and wrote up a guide on what I think you need to know and should do if you're going through it. I think it was overall incredibly straightforward, and the Yubico maintainers even added some additional functionality to their Java server-side library as I corresponded with them. To plug myself a bit, hopefully this can be helpful to others, and I'd appreciate feedback if you find it unclear: https://www.jacobcasper.com/u2f2webauthn.html https://www.jacobcasper.com/u2f2webauthn.html

ferdowsi 5y ago

The blog post is misconstruing things; WebAuthn is not totally backwards compatible with U2F. Specifically, WebAuthn doesn't support the U2F trusted facets functionality, which allowed for a U2F credential to be used on a cross-origin basis. https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-appid-and-facets-v1.2-ps-20170411.html https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid...

tialaramex 5y ago
Is anybody actually doing that? To me it looks like something that's astoundingly fragile and unwieldy and I'd expect that most "users" of this feature were either opening themselves up to a vulnerability they hadn't considered or were in fact attackers targeting such a vulnerability. Yuck.