[HN Gopher] Google Chrome U2F API decommission: What the change ...
___________________________________________________________________
Google Chrome U2F API decommission: What the change means
Author : vmoore
Score : 47 points
Date : 2022-02-05 19:20 UTC (3 hours ago)
(HTM) web link (www.yubico.com)
(TXT) w3m dump (www.yubico.com)
| captn3m0 wrote:
| Atlassian is the only site where I've gotten warnings about the
| old API being used.
| tazjin wrote:
| 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.
| kccqzy wrote:
| 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.
| dathinab wrote:
| 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 wrote:
| 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.
| devrand wrote:
| 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 wrote:
| 3 months is not a long time at all.
| paddez wrote:
| Especially not across the Holiday period.
| devrand wrote:
| 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.
| xxpor wrote:
| 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.
| jtcasper wrote:
| 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.
| jtcasper wrote:
| 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
| psanford wrote:
| 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/
| zinekeller wrote:
| 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.
| ferdowsi wrote:
| 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/fid...
| tialaramex wrote:
| 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.
| alopes wrote:
| As a YubiKey user, is this something I need to worry about?
| psanford wrote:
| No. Webauthn is backwards compatible with old u2f tokens, so
| reguardless of how old your YubiKey is, it will continue to
| work.
| dathinab wrote:
| 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.
| qudat wrote:
| 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 wrote:
| 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
| paulryanrogers wrote:
| 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.
| dathinab wrote:
| Oh god, that scared me for a moment until I realized what's going
| on ...
___________________________________________________________________
(page generated 2022-02-05 23:00 UTC)