6 ms·

One question I am unable to answer from all of these recent discussions: will I ever be able to use my phone as a cross-platform compatible FIDO/U2F hardware ke

One question I am unable to answer from all of these recent discussions: will I ever be able to use my phone as a cross-platform compatible FIDO/U2F hardware key? I don't want a vendor-specific or identity-provider specific integration like Google using Chrome and Android for MFA with Google accounts. I mean could my Android or iOS phone connect to a laptop via bluetooth or USB and act as a hardware key just as if I used a yubikey or titan key, and be visible to Firefox or any other software that knows how to talk to U2F or other smartcards to enroll with new websites and identity providers that have nothing to do with Google nor Apple accounts?

idle_zealot 4y ago
There’s no technical reason why your phone couldn’t do what you describe. But the goal here isn’t to maximize security or privacy, it’s to maximize convenience for the sort of person who already uses the same weak password everywhere for the sake of convenience. Plugging in their phone with a wire is too much to ask.
dwaite 4y ago
This is one of the main topics of the agreement discussed in the article - an agreement on how to use a phone as a cross-platform compatible authenticator and a commitment to do so. The mechanism is already available on chrome and android if you select the option to add an android phone - iPhones and iPads have a developer preview feature flag you can enable to work with this as well, and to have a Mac display a similar option when using the platform level support (aka Safari or certain native apps).
- saltcured 4y ago
  Hmm, the closest thing I saw to this is the "caBLE" cloud-assisted bluetooth. Reading more on this, it does not sound exactly like what I am seeking. It seems completely tied to the platform vendors and interactions over the internet. I wish for a completely local mechanism where a phone with a hardware security module could act like a token via completely local communication with the browser, both for enrollment and later login with any relying parties. For general users, I do like the idea of being able to backup/restore the token seeds to allow replacement of hardware without manually re-enrolling redundant keys with all relying parties. But, I don't see why the cloud-assist should interpose between the user agent and the security device, nor why a cloud-assist should interpose between the user agent and the relying party. How is this cloud-assist different than the other vendors like Duo and Okta, interposed in enterprise client login attempts and organizing MFA options which can include authenticator apps on phones? I feel like platform vendor lock-in has been gratuitously introduced into this plan. Couldn't a token backup/restore service be offered to users without interposing anything new service between the phone-as-token, the user agent communicating with the token, and the relying party service? Or, couldn't the token standards be amended with some sort of web-of-trust concept to allow a token to announce additional peer/backup token keys during enrollment. so that one enrollment task can simultaneously enroll the present token and offline backup token(s) with the same relying party?

idle_zealot 4y ago

There’s no technical reason why your phone couldn’t do what you describe. But the goal here isn’t to maximize security or privacy, it’s to maximize convenience for the sort of person who already uses the same weak password everywhere for the sake of convenience. Plugging in their phone with a wire is too much to ask.

dwaite 4y ago

This is one of the main topics of the agreement discussed in the article - an agreement on how to use a phone as a cross-platform compatible authenticator and a commitment to do so. The mechanism is already available on chrome and android if you select the option to add an android phone - iPhones and iPads have a developer preview feature flag you can enable to work with this as well, and to have a Mac display a similar option when using the platform level support (aka Safari or certain native apps).

saltcured 4y ago
Hmm, the closest thing I saw to this is the "caBLE" cloud-assisted bluetooth. Reading more on this, it does not sound exactly like what I am seeking. It seems completely tied to the platform vendors and interactions over the internet. I wish for a completely local mechanism where a phone with a hardware security module could act like a token via completely local communication with the browser, both for enrollment and later login with any relying parties. For general users, I do like the idea of being able to backup/restore the token seeds to allow replacement of hardware without manually re-enrolling redundant keys with all relying parties. But, I don't see why the cloud-assist should interpose between the user agent and the security device, nor why a cloud-assist should interpose between the user agent and the relying party. How is this cloud-assist different than the other vendors like Duo and Okta, interposed in enterprise client login attempts and organizing MFA options which can include authenticator apps on phones? I feel like platform vendor lock-in has been gratuitously introduced into this plan. Couldn't a token backup/restore service be offered to users without interposing anything new service between the phone-as-token, the user agent communicating with the token, and the relying party service? Or, couldn't the token standards be amended with some sort of web-of-trust concept to allow a token to announce additional peer/backup token keys during enrollment. so that one enrollment task can simultaneously enroll the present token and offline backup token(s) with the same relying party?