[briHass]

I'm calling it now: if/when this really takes off, this will absolutely be used as a way to lock users into the platform (OS and/or browser). Even the vendors that have committed to being open about 3rd party integration will close that loophole. It will be done 'in the name of security', because, ostensibly, Microsoft/Apple can ensure the keys are stored 'more securely' or the sync is easier.

Having the keys in your PW manager of choice is worthless if your browser/OS won't play ball. Keeping all those logins locked inside Apple/Google/MS's garden is just too juicy of a 'sticky' platform lock-in to ignore. Besides, only nerds care about integration of other key storage platforms; 98% of users will just keep them in iCloud/Hello/Google, so maintaining the APIs to enable that integration will be on the chopping block of every Product Manager.

e.g. look at Google's Authenticator app. Once you add a TOTP secret, you can't get it back out. Only recently did they add the ability to sync, but only to other Android devices you own. Those keys are hidden forever, for your protection.

[cmdli]

I would flip this argument around: if the only way to use passkeys effectively is to be locked into a single platform, then passkeys will never take off.

Login with Facebook has existed for years now, but not everybody with a Facebook account uses it, even if they can. Why? Because that vendor lock in means that people are discouraged from using it in all cases. Banks don’t want to use it. Other large websites don’t want to use it. Businesses don’t want to use it internally.

I think that there will be significant enough demand for 3rd party, open solutions that passkeys will succeed. If there isn’t that demand, then it will fail overall.

[briHass]

OAuth/OIDC flow through Facebook (or whoever) doesn't really have the same tight integration into the browser/OS that WebAuthn proposes, however. There's also no compelling reason for 'Website X' to support OIDC with Facebook/Google/Yahoo/other, because there's too many choices and if the provider of choice is down, your site is inaccessible to those users.

The major browsers and OSes already support WebAuthn, so it may be compelling for all 'Website Xs' to implement it, though the linked article presents a (dated) concern that they won't.

That's not the part I'm worried about: WebAuthn as a standard may work almost everywhere, but as a user, your ability to bounce around between browsers/OSes with your secrets coming with you may be restricted.

[politelemon]

None of your observations strike true, perhaps you are assuming too much thought on the part of the average user. People use 'Login with FB' (and others) because it is convenient, there is nothing more to it. It's only a small fraction of the population that are aware that choose to avoid using it due to the potential for lockin.

[spacebanana7]

Yeah the remark about businesses was more persuasive. Banks and other large B2C organisations are much more likely to care about commercial lock in and the compliance risks of using Facebook login than consumer users.

[TRiG_Ireland]

I have Facebook (albeit rarely used) and Google accounts. Many sites offer me the option to sign in with one or the other of those. I've used Google for Stack Exchange, but otherwise would never use these for anything. Both those companies know enough about me already.

[aseipp]

For passkeys in particular, this theory would be more credible if it wasn't for the fact pretty much every password manager has planned support for them, and almost all of those same managers have been integrated with your browser's password manager APIs and the OS's secure auth mechanism. 1Password will use Face ID or Windows Hello Pin to unlock your vault, and then it will offer up the passkey credential, just like it does with your completely randomly generated password, today, the difference being you can't phish them or recover them from hacking websites. Like this theory just doesn't work as well when we basically have years of evidence suggesting the exact opposite thing, which is that both major browser vendors and password managers are interested in cooperation in order to achieve better user experience and security.

Plus the idea is predicated on the idea you can't just register another device. Passkeys, as a user auth model, pretty much require the ability for multiple devices to be tied to one account. Google has your passkey for site X? Log in, register a new passkey with 1Password, delete your old passkey. Done.

[briHass]

Sure, for now. If it ever reaches wide adoption, when Google/MS/Apple see only 2% of users use a 3rd party to store keys, why would they continue to maintain the ability to integrate? Especially if there's some advantage (lock in) to not doing so.

Multiple devices/key stores that don't sync are dead before they even get started. Almost no users are going to be willing to do that, and thus most websites won't bother to support it. How many websites today offer the ability to have multiple OTP options concurrently and/or allow you to only enable TOTP and disable email/SMS?

This will start out open and flexible to gain adoption, and then either through malice, laziness, or low adoption, the options that avoid lock in will be phased out.

[josephcsible]

It doesn't matter how many different things have support for passkeys. Because they let websites do "attestation" of them, it won't be long until every major website is only allowing logins with passkeys blessed by Microsoft, Apple, or Google.

[5e92cb50239222b]

AFAIK Apple refused to implement attestation, so you can't realistically enforce it. Who knows how long that one is going to last, though.

[supriyo-biswas]

It’s incorrect - Apple has in fact implemented attestation as can be seen in https://github.com/lbuchs/WebAuthn.

[FullyFunctional]

I'm not familiar with all this, but when I run the demo page (https://webauthn.lubu.ch/_test/client.html) on macOS 13.4.1 with Safari (Firefox doesn't work) I get "none" for the apple attestation.

[notatoad]

this is entirely on the webapps.

webauthn, as designed, can't be used to lock anybody into any authentication method, because the apps that use it should support adding as many different webauthn methods as you want. it only has the possibility to be a lock-in if you are restricted in the number of authentication methods you can add for a third-party service you want to authenticate to. and FWIW, apple and google both recommend supporting infinite passkeys, and have implemented that in their own webapps. any fearmongering about webauthn/fido/passkeys being a vendor lock-in is not backed up by current facts.

[johncolanduoni]

WebAuthn has a specific feature called “attestation” where an app can only accept keys from a specific vendor as verified by vendor-provided signatures (that the user agent cannot forge). I personally doubt it will be used for this kind of lock in (it’s currently mostly used by companies for internal authentication so they can make sure you only use the brand of WebAuthn keys issued by them) but it’s not technically infeasible with the current standard.

If you want to see an outside of the box use of the attestation feature, take a look at Cloudflare’s “Cryptographic Attestation of Personhood” [1]. Basically they use the attestation key to tie the WebAuthn challenge to a real vendor, so if spammers make their own fake WebAuthn keys they can block them wholesale. I’m sure some Cloudflare skeptics will jump in and point out all the ways that could be abused.

[1]: https://developers.cloudflare.com/support/about-cloudflare/b....

[briHass]

The problem is how you get those keys, rather, the results of crypto functions on those keys, back to the requesting website. That process, 'Client to Authenticator'[1] relies on the goodwill of the 'Clients', which for all intents and purposes are: Chrome, Safari, Edge, Firefox, Windows 10+, iOS, and Android.

Maybe they'll always support cross-platform USB/NFC keys (they probably will), but I don't want an external device(s), especially if I have to remember to set up multiple devices for every site to have redundancy.

[1] https://fidoalliance.org/specifications/download/

[notatoad]

> The problem is how you get those keys, rather, the results of crypto functions on those keys, back to the requesting website

Yes. Good thing there's an open standard called webauthn, supported by all the major vendors, that defines an interoperable way to get the result of those crypto functions back to the websites that need them.

[SgtBastard]

The person you're replying to is clearly talking about the portability of the private key material across multiple, heterogeneous clients - which webauthn doesn't touch.

Be better.

[u801e]

> webauthn, as designed, can't be used to lock anybody into any authentication method

It only supports HTTP as I understand it, and won't work for other protocols like SMTP or IMAP.

What does work, regardless of application level protocol is using TLS certifications on both the client and server side in combination with a username and password for authentication.

[johncolanduoni]

WebAuthn doesn’t even support HTTP technically. All of the communication between the relying party and the user agent is non-standard and is handled by JavaScript today.

[nyolfen]

authenticator allows you to export your totp's via qr code, and the sync works for ios as well

[pohuing]

I recently tried to import and old backup which contained a key I thought was obsolete. But didn't have any luck. My up to date authenticator couldn't read the 2 years old export.

I've very hastily made sure that all my backup keys are up to date afterwards...

[briHass]

Fair enough. I stopped using it right around the time (~2 years ago?) when they finally added the ability to do an export. At that time, the compelling reason to use alternative TOTP apps was the ability to sync the secrets. I assume this feature was driven mostly because of said alternatives, rather than goodwill for such a simple/obvious feature.

I always did & do save a copy of the QR code or, if provided, the BASE64ed key in my PW manager. I know I'm never locked in with TOTP: I can use anything (I've written the 10 lines of code, even) to generate the code, and it can be entered manually on any device that can display the site's login page by hitting 6 digit-keys. WebAuthn needs, at minimum, the browser to remain open to integration.

[szasamasa]

so it is not a 2nd factor any more since with your master pass anybody can get any passwords and the totp codes

[davchana]

Not op, but my qr codes & strings are saved in a separate keypass database, saved in a different location & using different password (saved in my brain only).

[szasamasa]

vow :) thumbs up!

[szasamasa]

Why would Apple, Google, Microsoft CEO want to go to congressional hearings and put a big stain on themselves for 2% market share? I think they just want to get rid of passwords because there are good people working there too and it is a pain to pay for support.

Pass managers have totp authenticators as well. I mean really, you can just sit back and have Apple do everything for you (built in totp) or the same with Google or you get 10+ pass managers to choose from, some are open source... This whole thing is rather paranoia as of now.

We must be crictical and watch out but the law is on our side:

https://www.whitehouse.gov/briefing-room/presidential-action...

c-gpt free version:

It is theoretically possible for a dominant company to support a third-party technology or standard initially and then abandon it, which could potentially harm competition. This practice is known as "embrace, extend, extinguish" or "embrace, extend, and extinguish" (EEE). The term was coined during the Microsoft antitrust case in the late 1990s, where Microsoft was accused of using its market power to undermine competing technologies.

In the case of passkey technology or any other standard, if a dominant company were to initially support it, attract third-party developers and users, and then suddenly abandon or change the technology in a way that hampers compatibility or competition, it could potentially limit the options available to users and stifle innovation from other companies.

However, it's important to note that such practices can be subject to scrutiny and legal action under competition laws. Antitrust authorities, such as the DOJ and FTC, are responsible for investigating and addressing anti-competitive behavior. If there are indications that a company's actions are harming competition or violating antitrust laws, regulatory authorities may step in to assess the situation and take appropriate measures.

[calgoo]

Yea but these days they will get some stupid fine like $30m which is a rounding error for these companies. Especially in the US where bribes are legal, and it has been proven over and over that the politicians will do whatever their corp overlords tell them to do.

[szasamasa]

I believe they would be then forced to open up, not just fines.

Free pass management is really a basic human right (or democracies can make them to be). I personally do not hate Apple, Google, Microsoft but they own 99% of OS I guess so if passkeys take off, they have to remain open.

I mean at least Europe and California (and the rest of the World that is not US) and even US citizens would back competition in pass management sector. What we really needed is a good Linux phone. Now I use Google stuff but I would change to full Linux+Proton I guess. They just announced their open source pass manager!

I am not saaying we should not be vigilant but I guess we are stronger than you might think (I mean we vs. a heterogenous not-really-oligopoly-us-os-providers).

[esafak]

Same with Authy! I hate that ****. I'm migrating to 1Password, which lets you export the secret.