31 ms·

Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

426 points by KoftaBob 4y ago

account-5 4y ago
Genuine question. What benefit does this FIDO system provide over my password manager? I've read the what is Fido page and what Fido does page. I don't get it. It seems like the device is a single point of failure.
mark_l_watson 4y ago
Does anyone here know what privacy/tracking issues are with this standard?
- jeroenhd 4y ago
  I haven't found any so far. Each account gets a new public/private key pair so accounts can't be traced back to each other. Usernames are optional and might even become a thing or the past, making username reuse less of an issue for linking accounts. It all depends on the sync method provided. If synchronisation isn't end-to-end protected, you're handing Apple/Google/Microsoft the keys to the kingdom which is pretty bad.
- bachmeier 4y ago
  It fully resolves all existing privacy and tracking issues. You will have no privacy and will be tracked all the time. Problem solved.
- 0daystock 4y ago
  FIDO2 privacy is actually pretty good and well thought out. There's a theoretical risk of a website sending authentication challenges for two different accounts and having both assertions signed by the same credential, basically correlating those accounts together, but this is unlikely to weaken collective privacy at scale.
  - RL_Quine 4y ago
    Kind of. Yubikeys intentionally have a very small number of devices signed with one CA key and then they produce a new CA key, so those devices do have a basically unique identifier.
    - 0daystock 4y ago
      Can you share any more information about that? Is this identifier shared as part of the FIDO2/U2F spec?
      - md_ 4y ago
        I think they're referring to attestation (https://fidoalliance.org/fido-technotes-the-truth-about-attestation/#:~:text=Making%20sure%20that%20attestation%20certificates%20are%20used%20across%20large%20batches%20of%20authenticators%20of%20the%20same%20model%20(100%2C000%2B)%20ensures%20that%20users%20can%E2%80%99t%20be%20tracked%20based%20on%20their%20attestation%20certificate https://fidoalliance.org/fido-technotes-the-truth-about-atte....), which requires that attestation certificates be shared with a minimum of 100,000 other devices in order to ensure they're not unique IDs. Maybe the parent misread the spec as saying a _maximum_ of 100,000? Or something?
        dane-pgp 4y ago
        The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked. Also, the Alliance could decide to blacklist a manufacturer just because they haven't implemented some new policy (like requiring a DNA scan of the user) so you better make sure that you buy a device from one of the "too big to fail" providers.
        md_ 4y ago
        > The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked. 1. By what mechanism can they blacklist a device? A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust. But that's between you and the RP. Authentication doesn't "talk to" the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys, so I don't understand what you are talking about here. 2. The intention of the attestation, as I understand it, is to enable RPs to use attestation to limit authenticators to e.g. those that pass FIPS certification (or similar enterprisey requirements), not to ban a whole batch because one key is known to be compromised. That's crazy; can you point out where anyone other than you has ever proposed this? 3. DNA scan? What are you talking about? 4. This assertion you are making, while bizarre and wrong, is very different than the assertion the grandparent made ("Yubikeys intentionally have a very small number of devices signed with one CA key...so those devices do have a basically unique identifier"), which, while also wrong, is I think a genuine mistake and not a bad-faith argument.
rvz 4y ago
Not a great thing to see the big three once again, driving the standards here. You should be worried. But as long as the ridiculous SMS 2FA is removed or replaced by something better, then fine. But we'll see how this goes. From the web side of this standard, this also tells me that Mozilla has no influence anywhere and will be the last ones to implement this standard in Firefox. Oh dear.
- theklr 4y ago
  Both FIDO and W3C are neutral places for this. Mozilla being a part of W3C and FIDO will have a say. This is just a PR stunt that the tech journalists ate up. They’ve been working together to make this for the last two years, it’s just an announcement to accelerate the work on it.
- jeroenhd 4y ago
  Mozilla is a member (https://fidoalliance.org/members/ https://fidoalliance.org/members/), so I doubt they'll be the left to their own devices. They'll probably lack the manpower to implement the additions well (I mean, you can't even paste a URL to an IPv6 address in Firefox for Android, which is one of the most basic features of a browser), but then again they already have Firefox Sync and a working WebAuthn system.
  - deleted 4y ago
    [deleted]
- deleted 4y ago
  [deleted]
bcatanzaro 4y ago
This passwordless signin process sounds neat, but will it increase Google’s power to lock people out of things? I don’t understand why Google doesn’t have an ombudsman - consumers have no recourse when Google locks them out, and it seems the consequences of Google locking you out are ever increasing. I think we’re going to need legislation to force Google to make a proper appeals process.
- moritonal 4y ago
  At some point (unless you're an Android dev) you have to accept a bit of responsibility. If you use Gmail, Drive and Android and then decide to use Android as your preferred implementation of FIDO (when YubiKeys ect, exist) I struggle to see how if you're locked out it's not partially the consumer's fault. You choose to use Google, and can attest to the fact it's not that difficult not to.
- ThunderSizzle 4y ago
  Don't use Google Drive. Don't use Gmail. That solves half the horror stories already.
- CyberRage 4y ago
  how FIDO has anything to do with google in particular? log in with google is not FIDO authentication...
- judge2020 4y ago
  Google's power to lock people out of their website is already here with Oauth2. This standard is unrelated; it works by having the browser/device itself sync the virtual security keys[0], much in the same way they sync passwords currently. That's the only thing changing here, giving people the choice (and encouraging them) to sign in via "what you have" instead of "what you know", but along with that they want to alleviate the UX concerns of people not being ready to carry around a separate physical security key. 0: https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys https://developer.apple.com/documentation/authenticationserv...
jeroenhd 4y ago
I hope this cross device system will be cross platform, but I wouldn't be surprised if you could only choose between macOS/iOS, Chrome/Chrome, or Edge/Edge sync. Funnily enough, a system for signing web authentication requests from a mobile device is far from new: I've been using https://krypt.co/ https://krypt.co/ for years (though it's on the long road of sunsetting right now) and I hope that will last long enough for the new cross device standard to replace it.
- sdfgdfgbsdfg 4y ago
  It won't, at least not in the short term. For that to happen trusted platform modules would need an api to export a private key wrapped with a certificate signed by (none/one/all/a quorum) of members in the circle of trust and itself. This will need standardizing. Only apple has implemented it so far because it has total control of their ecosystem. I think for Windows and Chrome to work like this, they'll need to start requiring TPM vendors to implement this in their drivers, but I can't see it being cross compatible with the API in the apple TPM any time soon, especially because the circle of trust is now as weak as the weakest TPM, and it's a reputation risk for apple if a credential gets compromised because some non-apple device trusted by the user in an apple circle of trust got breached
  - jeroenhd 4y ago
    I think the first iteration of this system will definitely receive the synced key material in RAM. It's possible that the TPM spec will be updated to allow for loading pre-encrypted data into the TPM store as a response to this. Alternatively, existing secure computing systems (SGX/TrustZone) can also be used to decrypt the synchronised key relatively securely.
    - sdfgdfgbsdfg 4y ago
      receiving synced key material in RAM significantly alters the threat model. Apple's current passkey implementation does not, at any point, handle unwrapped key material in the operating system. I expect all other implementations to follow.
missosoup 4y ago
So their vision of the future is that to do anything online, one MUST have a phone (ahem, portable wiretap)? And they're going to be keeping my secrets for me, for my own good? I'm not sure I'm down with any of that.
- jeroenhd 4y ago
  I doubt they'll do away with tools like smart cards or Yubikeys any time soon. Laptops and modern computers also contains a TPM so you don't necessarily need to have a phone for secrets storage. If push comes to shove, I'm sure someone will develop a lightweight Android emulation layer you can run in the cloud that pretends to be a phone enough that you can use it.
  - dane-pgp 4y ago
    > Laptops and modern computers also contains a TPM The root of trust for which extends to who knows where, and you're not allowed to look at the source code or learn how it works because that would threaten Hollywood's profit margins. We're basically building a system of DRM for access to human beings, and making the whole world dependent on these unaccountable entities.
    - jeroenhd 4y ago
      TPMs allow for arbitrary key storage by the operating system. They're not necessary for DRM. In fact, I've wiped my TPM several times to upgrade the firmware and I've had no trouble playing DRM content whatsoever. Technologies like Intel's management engine and SGX or their AMD/Qualcom/Apple counterparts are definitely problematic for user freedom in the way they're implemented. However, the TPM system itself is quite neutral: usually, you can clear it from the UEFI, lock it with a password (though that might need to be done from the OS) leaving whatever hostile OS you may run unable to exert any control on the device whatsoever. I'm personally a big fan of technologies like TPMs and secure boot as long as they're user configurable. I want to be able to install my own keys and force the system to only boot operating systems of my choice. Secure boot with just the MS keys is quite silly and ever since that one version of Grub could be exploited it's basically useless; secure boot with user or enterprise keys can be an incredible tool for defence in depth, for example when visiting countries where border agents may try to gain access to your data without your permission or knowledge (China, USA, etc.). If I had my way, I'd use Coreboot together with Secure Boot, with encryption keys stored in a TPM, the transfer of which goes through an encrypted channel (a feature of TPM 2.0 that nobody uses) after unlocking it with a password. Sadly, most Linux OS developers have a grudge against these technologies because they're used by companies such as Microsoft and Apple to reduce user freedom on some of their devices.
deleted 4y ago
[deleted]
foobarian 4y ago
I feel like I woke up in some parallel universe where TCP/IP didn't take off and FidoNet ended up as the Internet.
- chondl 4y ago
  I had the same thought. Living in the past.
TIPSIO 4y ago
I’m sure people way smarter than me have this figured out, from the Google post: > When you sign into a website or app on your phone, you will simply unlock your phone — your account won’t need a password anymore. > Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone So if I was a dumb kid, I could login to my parents bank accounts (or more / worst) if my mom gave me her 4 digit phone password for games earlier?
- amelius 4y ago
  No, because it should be evident by now that a phone is a personal computer, not to be shared with other people.
  - josteink 4y ago
    I can tell you don’t have kids ;)
  - wlesieutre 4y ago
    And personal computers have supported multiple people with separated data and settings since what, the 1980s?
  - jeroenhd 4y ago
    For you perhaps. Phones are shared more often than you think. And no, they don't use multi-account features built into modern mobile operating systems.
- davidkhess 4y ago
  Normal usage would require a reauthentication - i.e. FaceId or TouchId - to produce the passkey.
  - kogus 4y ago
    Currently on the iPhone, if your FaceID or TouchID fail repeatedly, you have the option to type in the passcode, which grants the same access. I'm not sure if the same is true on Android. I think the more general point is that "able to unlock the phone" is not / should not be the same as "I have verified that this is you" for sensitive applications and information.
josteink 4y ago
That’s a whole lot of text saying “things will be simpler” on repeat, without specifying how things are going to be and why that is simpler. Anyone got a link to something less hand-wavey and more concrete?
davidkhess 4y ago
I think this is really great news and am glad to see FIDO move forward as I think it greatly increases account security. One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. OOB recovery with SMS or email is considered too weak and the main recommended alternatives are to maintain multiple authenticators (i.e. multiple copies of your passkeys), re-run onboarding processes for new users or just abandon the account. It's going to be interesting to see how those alternatives play out in real world situations.
- jeroenhd 4y ago
  Reading this announcement, the idea seems to be that FIDO keys will be synchronised across devices. That means you can lose your phone and still get access to your accounts from your desktop. You might even be able to get access by simply logging in to your Microsoft/Apple/Google account on a new device if they implement this system stupidly enough.
  - davidkhess 4y ago
    Yes, these will be stored in cloud storage like iCloud Keychain. But I can go into my iCloud Keychain and delete individual passkeys - or I may have only one Apple device and then lose it. Or some malware clears out all of my iCloud Keychain.
- microtonal 4y ago
  One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. I think the idea is that passkeys are synced between devices, see e.g.: https://developer.apple.com/videos/play/wwdc2021/10106/ https://developer.apple.com/videos/play/wwdc2021/10106/ I haven't look deeply into passkey enough yet, but aren't we replacing "what if I lose by device" by "what if company XYZ decides to nuke my access to my synchronized passkey"?
photochemsyn 4y ago
Suggested edit of mission statement in the name of increased accuracy: “The standards developed by the FIDO Alliance and World Wide Web Consortium and being led in practice by these innovative companies is the type of forward-leaning thinking that will ultimately make the American people easier to track online. This will be done by linking all online activity to unique personal attributes, i.e. "their fingerprint or face, or a device PIN." It's basically another step towards the China model of total mass surveillance of the population. [edit: all the justifications for this proposal - aren't they mostly solved by the use of password managers?]
alberth 4y ago
Dumb question: why are biometrics being used to replace the password, shouldn't the biometric replace the username?
- sph 4y ago
  Sounds to be like we're replacing the username and the password, i.e. something you know with username and your phone, i.e. something you have. It sounds like it's still a one factor authentication system, but different.
  - alberth 4y ago
    Follow-up dumb questions: - so what happens if you don't have your phone at time of login? - if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms? - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
    - maxfurman 4y ago
      If you don't have your phone, you can't log in. SMS 2FA has the same problem. You technically should be able to migrate from one provider to another, it remains to be seen how easy Apple and Google will make the process. That last one is a great question that I don't know the answer to.
      - judge2020 4y ago
        > You technically should be able to migrate from one provider to another, it remains to be seen how easy Apple and Google will make the process. On a UX level, the transfer to another syncing security key "provider" is going to be interesting, if they even do that at all - I kind of doubt they'll have a "transfer your iCloud passkeys to your Chrome password manager" and they'll instead say "go to each service and enroll a new security key via your new syncing key manager". On a technical level, I wholly imagine there'll be a tool that pulls iCloud Passkeys[0] via the MacOS Keychain application and then inserts them into your new key manager. 0: https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys https://developer.apple.com/documentation/authenticationserv...
throwaway52022 4y ago
I've resisted switching to a hardware key because I know that I'm going to break it, and that seems like a huge pain in the ass. I really want to be able to make a couple of backup keys, or maybe put another way, I want to be able to put the private key on the device myself, I don't necessarily care that the key is generated on the device and never leaves the device. I don't care if that slightly reduces my security - I'm not protecting nuclear weapons, my threat model is not state actors trying to attack me, my threat model is me leaving my key in my pants pocket before putting it in the washing machine.
- vngzs 4y ago
  You just register 2-3 keys. It's not so bad.
  - georgyo 4y ago
    It's actually horrible! Even key rotation is horrible! My yubikey is getting to about 10 years old, and I have replacements for it but find it very difficult to switch. It will eventually fail as an things do and it will be problematic. The problem is that I have several dozen accounts connected to it and I don't know all of them. So either I'm carrying and trying multiple keys at all times or not getting into a site that haven't been rotated yet. Multiple keys on an all sites is also basically impossible. You need to register all the keys, and ideally those keys are in different places.
    - bpye 4y ago
      I’m going to need to work this out soon. I picked up a pair of new YubiKey 5Cs yesterday with their sale. I’ve been using a YubiKey Neo for years for U2F, TOTP and GPG. Moving the GPG key is easy - though I might try using the FIDO2 support in SSH instead. However for every TOTP and U2F key I’m going to have to re-enroll the new keys… It feels like there should be a better way.
      - bradstewart 4y ago
        It would indeed be nice if you could "cross sign", CA style, a new yubikey with an old one, and that would somehow get passed along to the various services. I have not thought about the various attack vectors that this may or may not enable though.
deleted 4y ago
[deleted]
Andrew_nenakhov 4y ago
Played with the Yubikeys a couple of days ago. Rather nice thingies that are very easy to lose somewhere.
- 0daystock 4y ago
  It's reasonably safe to leave them connected to the devices you regularly authenticate from, unless your threat model includes an adversary willing to use physical attacks.
  - oynqr 4y ago
    Unless you have some way of authenticating all of your hardware with the key, taking it with you still leaves plenty of options for a physical attacker.
criddell 4y ago
It seems like FIDO is going to win the race for the next generation authentication scheme. I was rooting for Steve Gibson’s SQRL.
- davidkhess 4y ago
  Last time I looked at SQRL, it had an unfixable man-in-the-middle problem. Though, general acceptance of QR Codes does seem to have finally taken off.
bedast 4y ago
The weakest link in security is always going to be humans. Account compromise is is more often a human problem than a technological one (spamming requests, password reuse, simple passwords, (spear) phishing, direct social engineering, etc). If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords. Easier to use. Easier to social engineer a compromise. I get regular requests to get into my Microsoft account using their new login form that sends a key code rather than prompting for password. "Passwordless" just means that prompt goes to an app where a user unlocks their device to approve the login. This seems like worse security, not better. I'm okay with an approval prompt if it's part of a multi-factor auth system. Not if it's the only auth.
- j_san 4y ago
  But isn't the "thing" about FIDO (or maybe just security keys?) that the domain is also integrated into the challenge the client/key has to solve? So from what I understand a attacker couldn't as easily fish me by pretending e.g. to be Google. With a password or even a TOTP code the attacker could just pose as Google and forward the credentials to the actual site.
  - bedast 4y ago
    You're looking at an exploit from a technological point of view, which I expect this community is likely to do. Think of it from the perspective of the average user. I know for a fact if my mom was told by an attacker "if you see an approval request for your account, just accept it" she would do so. It's taken time to train her not to give anyone her password. I've read of attackers with valid passwords spamming logins in hopes to trick a user into approving the auth. Whether it's because it woke up the user and they're in a sleep fog, or they're busy and not paying attention. Microsoft, at some point, changed their login flow so that, by default, when you enter your username, it sends a pin. I receive regular attempts at this. This isn't going to work out for the attacker because they have to get the pin. But if all that's required is a button press, the attacker could just make the login request and wait. With multi-factor auth, where a password is in use, you have to get past the password before getting to that auth approval. It reduces how much noise the user gets and the chances of success for the attacker.
danijelb 4y ago
I'm glad to see that the tech industry seems to be re-learning that creating and adopting interoperable standards is a way to go
throwaway52022 4y ago
I don't trust Google or Apple to be my main authentication provider, or to manage syncing my private key. Their customer service is terrible and they are way too arbitrary on locking folks out. I would trust my bank (well, my credit union.) I can go see them in person if I need to and they take my lawyer seriously, they also take security seriously, they're properly regulated, and ultimately they're my main concern if someone stole my credentials, so I'd like them to be on the hook for protecting my credentials.
- 0daystock 4y ago
  This announcement isn't about that and neither provider is asking to sync your private key. In fact the opposite is true: with FIDO2, you're in much greater control of your account security because authentication creds are now on a hardware token versus as bearer credentials you type and an adversary can steal and replay. Many of us believe we're very good at protecting our passwords, but this isn't true in reality and FIDO2/U2F standards objectively make accounts more secure precisely because they remove humans from the equation.
  - throwaway52022 4y ago
    Except it kind of is - the way I read this is "Apple/Google will turn your phone into a hardware FIDO token, but will use iCloud/whatever to reduce the huge painpoint of having more than one hardware token and keeping them all in sync" I really love the idea of FIDO and making sure that my authenticator only authenticates to sites that I've approved, but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future.
    - toomuchtodo 4y ago
      Your average user is more concerned about losing their password than they are about authenticator sovereignty. Moving towards cryptographic primitives for auth versus shared secrets is a net benefit versus current state. > but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future. Compromise is necessary, and probably a bit of regulation from government to enforce good outcomes from exception handling. Passkeys need to be stored and managed somehow, and your average user does not want to do that, just like they don't want to run their own mail server, syncthing instance, or mastodon instance. EDIT: (HN throttling, can't reply) @signal11 You can already be locked out of all of those accounts without recourse.
oversocialized 4y ago
kragen 4y ago
Jeez, I hope they don't expect us to put them in charge of the nodelist for Zone 1.
brightball 4y ago
Finally! Assume every password for every user on your site has been leaked. What now? This dramatically reduces the potential exposure to phishing and password leaks.
WaitWaitWha 4y ago
I like the idea, but not sure about the implementation. What happens when there is an outage at Google or Apple? What happens when I lose/get stolen/break/change my cell phone? What happens if I do not have/want a cell phone?
- pionar 4y ago
  > What happens if I do not have/want a cell phone? WebAuthn works with hardware tokens, so something like a Yubikey will also work.
- judge2020 4y ago
  The FIDO Standard talked about here includes regular security keys, so, if you don't want to use passkey, you can get a physical security key; and while I imagine the push for passwordless will be large, I doubt they'll completely remove passwords anytime soon.
mordae 4y ago
LOL, I was expecting the title to continue "... Fraud, According to $EU_COUNTRY Government". Seems like I don't trust them.
earthboundkid 4y ago
Aw yeah, BBSes are back baby! One question, who is going to pay for all the long distance calls?
- deleted 4y ago
  [deleted]
stjohnswarts 4y ago
no thanks. I don't want one account that apple/google/whoever can revoke and ruin my online life. fuck that. I'll take my chances with 2FA and passwords. When it finally gets breached (if you haven't been cancelled!) imagine how much one online cracker will able to do. This also allows them unlimited access to follow you all around and see what you do, where you log in, etc.
- _trackno5 4y ago
  > I don't want one account that apple/google/whoever can revoke and ruin my online life What are you even going on about? As long as you have access to your FIDO authenticator, you'll still be able to use it regardless of what they do with your account.
- deleted 4y ago
  [deleted]
aftbit 4y ago
Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.
- zozbot234 4y ago
  Is this actually needed? Looks like the online part of this is just WebAuthn, which could be supported by the same tools we use for TOTP. You would "enroll" a visible master secret that you could then back up and optionally store in a hardware security key. The device itself wouldn't need to allow for extracting the secret again, because you backed it up at enrollment.
  - lrvick 4y ago
    Ledger and similar hardware wallets support one time BIP39 backup covering all current and future accounts today.
- jupp0r 4y ago
  Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.
  - jedberg 4y ago
    While it's not a bad idea, I'm pretty sure Yubikey recommends a backup key so that they can sell twice as many Yubikeys.
  - Zamicol 4y ago
    "providers allow you to register multiple keys" Why isn't my identity just a Merkle root? I don't understand the need to register individual keys.
    - giaour 4y ago
mrkramer 4y ago
I never understood why TLS Client Authentication[0] is not used more because that way all other standards including FIDO wouldn't be needed. [0] https://blog.cloudflare.com/introducing-tls-client-auth/ https://blog.cloudflare.com/introducing-tls-client-auth/
- jedberg 4y ago
  It's the classic key distribution problem. You'd have to get client certificates to people securely. It works for corporations because they can send you a device with the client cert pre-loaded.
  - NovemberWhiskey 4y ago
    Firstly, PKI generally doesn't have a key distribution problem because keys never get distributed; they get generated in-place, certificate signing requests are sent to certificate authorities, certificates are signed and returned. Secondly, in the TOFU model that applies to WebAuthn, you don't even need to have a certificate authority - you can self-sign. The problem is really, as alluded to another comment, that if you share a single certificate across multiple sites then you are sharing a common tracking id between them (e.g. your certificate fingerprint). Logout is also a user experience pain point unless the certificates are stored on e.g. a smart card that can be removed.
- zozbot234 4y ago
  Client certificates have privacy concerns when used with ordinary web sites, as opposed to the API requests assumed in that blogpost. WebAuthn provides a tweaked featureset that addresses these concerns.
- NovemberWhiskey 4y ago
  Within the DoD, it's ubiquitous. see https://en.wikipedia.org/wiki/Common_Access_Card https://en.wikipedia.org/wiki/Common_Access_Card
lizardactivist 4y ago
FIDO also enables great opportunities for tracking. But we're not supposed to talk about that.
- md_ 4y ago
  Hmm, what opportunities? Genuinely curious what you mean here.
  - aaaaaaaaata 4y ago
    If you use the same public keypair across many unrelated sites, an observer could blah blah blah
    - md_ 4y ago
      Nope. See SG-4: https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-security-ref-ps-20141009.html https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fid....
eulers_secret 4y ago
Is there any way to use this system without an extra device (no phone, no key, only my pc)? If not, is there a FOSS implementation of these required new devices? Maybe an emulator for one? Can I download an manage my own keys, manually? Can I self-host the authentication layers so I don’t need to use a 3rd party?
- sjustinas 4y ago
  > Is there any way to use this system without an extra device (no phone, no key, only my pc)? I've used rust-u2f in the past, although it seems to be Linux only. https://github.com/danstiner/rust-u2f https://github.com/danstiner/rust-u2f
  - eulers_secret 4y ago
    Thanks, I’ll check it out! Looks like it answers some of my concerns. Super cool!
beefee 4y ago
I fear services will force the use of certain devices, like those on the FIDO certified products list [0]. Will there be a way to use open hardware, open firmware, and user-controlled hardware attestation keys? Or will that be considered a fraud/bot risk? [0] https://fidoalliance.org/certification/fido-certified-products/ https://fidoalliance.org/certification/fido-certified-produc...
RandyRanderson 4y ago
Saved you a goog and pop-over: "FIDO ... is an open industry association ... whose stated mission is to ... help reduce the world’s over-reliance on passwords" https://en.wikipedia.org/wiki/FIDO_Alliance https://en.wikipedia.org/wiki/FIDO_Alliance
fmakunbound 4y ago
Reading through the threads here: If the HN can't articulate FIDO and differences between it and the now decades old password model to each other, I think regular jack-offs are going to have trouble. People have the mental model that their secret is stored in their gray matter/post-it note/password manager, and now you're telling them it's in their phone, and somewhat related to the phone's security model, or maybe a "yubikey", or behind biometrics, or maybe not, it depends, and Big Co. has copy, of something, and it's synced, and one possibly "migrates" between Big Co. and Big Co. might deliberately/accidentally disable all your websites, or losing your device/yubikey/piece of paper means you're screwed, possibly...
- deleted 4y ago
  [deleted]
- toxik 4y ago
  Unrelated to what you wrote, but it is actually jagoff or jag-off. It is not related to jacking off.
- deleted 4y ago
  [deleted]
- stavros 4y ago
  FIDO is an authentication standard. It doesn't care where your secrets are, it just mandates a way to use them to log in to websites. You can still use a password manager, it will just basically contain a single encryption key for all sites.
- rad88 4y ago
  Yeah, well what I want is a (physical, literal) membership card like I have at the gym or library. I think "regular" people can learn to use USB tokens, and that they might make more intuitive sense than passwords. These places don't challenge me for the "secret password" when I come in, I just present or scan my card. It's very tricky obviously, in terms of engineering and operations, for an internet based company to arrange anything similar. But I don't think it's too mentally foreign for the user (assuming we develop good standards). So cards make sense to me. Way more sense than passwords. Maybe someone else feels more comfortable with the details living inside their phone, but that doesn't affect my mental model. Users don't need to understand or be taught the entire standard.
teeray 4y ago
Does this provide any benefit over a (properly used) password manager? I’d be happy with just: - an “alphabet”, “minlength” and “maxlength” attributes on password fields so password managers generate perfect passwords every time - a well-known URI for password managers to do zero-touch password rotation. - actual elements for login components to close the confused deputy attack for password managers. All these things would be much easier changes for crufty old sites to make, which would aid adoption.
- yakak 4y ago
  First you need to invent a password manager that can be properly used? The one I have runs on my computer and trusts everything else I've ever installed not to have put in a mechanism to observe memory allocated to my browser.
  - teeray 4y ago
    Is that how most credentials are stolen these days?
    - Sahbak 4y ago
      Most attacks are social engineering. Everything else, to the best of my knowledge, does not target passwords
      - judge2020 4y ago
        The biggest attack is persistent login tokens that are stored on a device, eg. Discord has an issue with malware (disguised as DMs from random people asking "do you want to try out a beta for my game") that steals the login token from appdata, using it to purchase a bunch of gifted nitro and perpetuate the scam via that user's account.
    - raxxorraxor 4y ago
      Users opening shady attachments or going to amarzön.se and logging in are probably 99% of cases.
Animats 4y ago
Does this imply that every service you connect to knows your unique identity?
- diffeomorphism 4y ago
  No.
- NovemberWhiskey 4y ago
  No; each site to which you authenticate gets a separate, probabilistically unique credential id.
- Mindless2112 4y ago
  No, each registration generates a new key pair; but maybe: > The signature counter is a strictly monotonic counter and the intent is that a relying party can record the values and so notice if a private key has been duplicated, as the strictly-monotonic property will eventually be violated if multiple, independent copies of the key are used. > There are numerous problems with this, however. Firstly, recall that CTAP1 tokens have very little state in order to keep costs down. Because of that, all tokens that I’m aware of have a single, global counter shared by all keys created by the device. [...] This means that the value and growth rate of the counter is a trackable signal that’s transmitted to all sites that the token is used to login with. http://www.imperialviolet.org/2018/03/27/webauthn.html http://www.imperialviolet.org/2018/03/27/webauthn.html
CKMo 4y ago
This is a good step forward, I just hope they work on ensuring the end user experience for less technical people doesn't seem more complicated than passwords. It's a work in progress.
austinbv 4y ago
The problem with any key based auth or biometric auth is a user can be compelled by LEO to hand over private keys or open a biometric lock. Passwords are protected by the 5th amendment.
- Rafert 4y ago
  The actual exchange with the server is using public key cryptography. How you unlock the key material locally could be a number of ways: PIN, password, fingerprint scan, voice recognition, etc
- la6472 4y ago
  Why do we need another AuthN protocol? We should extend OIDC as needed instead of again trying to reinvent the wheel.
  - bdamm 4y ago
    Because the interaction with the hardware authenticator is local. OIDC and WebAuthn can work together.
  - drdaeman 4y ago
    In WebAuthn you're actually in possession of your own identity (or, to be more precise, your identity is established between you and website). In OpenID, OAuth and OpenID Connect the paradigm is completely different, where your identity is provided by someone else.
    - la6472 4y ago
      Yes I get that but I think OIDC could be extended to cover that too whereas the Authenticator or iDP is the local face scanner kr other biometric and then the rest ie exchange of token etc stays the same. That way there won’t be two completely separate path and that will defeat the purpose of SSO. And it looks like there are already some implementation of this https://www.bioid.com/facial-recognition-app/ https://www.bioid.com/facial-recognition-app/
- deleted 4y ago
nekomorphism 4y ago
daenz 4y ago
It would be nice for Amazon to commit as well. AWS has support for only a single Yubikey, which is mostly useless, unless you don't care about being locked out of your account if you lose that one key.
- aaaaaaaaata 4y ago
  Yeah, they should be ashamed of themselves — forget losing it, what if it fails...? It's bad practice to register just one hardware key, if your service has no side-doors.
- arianvanp 4y ago
  They support multiple if you use AWS SSO instead of IAM directly though.
ChikkaChiChi 4y ago
Why aren't we doing more to validate the identity of the service we are trying to connect to? CAs don't allow me to establish my own personal web of trust. If I connect once to my bank in a method I deem safe, I should be able to store their credentials in an easy to validate way. That way if I fall for a phishing attack, the browser can CLEARLY indicate to me that I'm encountering a new entity, not one I have an established relationship with. Concurrently, OSes need to do a way better job of supporting two factor locally and out-of-the-box. To even use a yubikey personally you have to install their software and disable the existing login methods or else you can still login the original way you set up. While we're at it, browsers and operating systems should actually lock out the second a key is no longer connected/in range. I know smart cards can behave similarly, but this needs to be grandparents level of easy to set up and control. I would feel much safer with my elderly family having "car keys" to their PC.
- Arnavion 4y ago
  They closest thing to avoiding being phished by a different "secure" entity is that your password manager will refuse to autofill (*) your credentials. But it's true that this is far from sufficient - this kind of autofill is wonky and doesn't work with all pages, so users can get conditioned to working around it by manually copying and pasting from the password manager to the browser, which defeats the protection. Many users prefer to always copy-and-paste anyway, because that avoids having to install the password manager's corresponding browser addon which can seem more secure. (*): Note that "autofill" only means "automatically populate credentials", not "automatically populate credentials without any user interaction". Clicking the username field, choosing a credential from a dropdown that the password manager populated for you based on which credentials match the website in question, and then having it be applied is also "autofill".
  - ChikkaChiChi 4y ago
    You're right, that's woefully insufficient. The authentication challenge should clearly (using color and text) whether or not the challenge is an established part of your trust network and the hardware token should be able to validate the authenticity of the challenge modal itself. Users should be able to take an action they trust, while at the same time having the choice of that action taken away (or made more cumbersome) if they are about to get themselves into trouble. There are people far smarter than me working on these problems, but I feel like they are so hyperfocused on state-security that they refuse to listen to anyone regarding actual usability.
EGreg 4y ago
Can I use the webauthn API to have the user confirm arbitrary actions or only authenticate? Like, what if I send a different challenge every time?
Ajedi32 4y ago
This is huge! It sounds like they're finally going implement cross-device synced credentials; a move I've been advocating now for the last two and a half years[1]. Widespread support for this feature is, in my opinion, the last thing needed to make WebAuthn viable as a complete replacement for passwords on the web. The white paper is here: https://media.fidoalliance.org/wp-content/uploads/2022/03/How-FIDO-Addresses-a-Full-Range-of-Use-Cases-March24.pdf https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... Seems like they announced this back in March and I missed it somehow. [1]: https://hn.algolia.com/?query=ajedi32%20webauthn&type=comment https://hn.algolia.com/?query=ajedi32%20webauthn&type=commen...
- PostThisTooFast 4y ago
- la6472 4y ago
  I get that but I think OIDC could be extended to cover that too whereas the Authenticator or iDP is the local face scanner kr other biometric and then the rest ie exchange of token etc stays the same. That way there won’t be two completely separate path and that will defeat the purpose of SSO ie OIDC websites will authenticate with google or Facebook but FIDO enabled websites will work with face recognition. And it looks like there are already some implementation of this OIDC enabled face recognition https://www.bioid.com/facial-recognition-app/ https://www.bioid.com/facial-recognition-app/
  - dwaite 4y ago
    1. You can use OpenID Connect as a protocol to integrate (via federation) with a site that provides authenticator management. This is AFAIK how most deployments work today - even if that OpenID Provider winds up being something you run or you pay to be run for you (AKA a CIAM solution). 2. There is an upcoming specification, Self-Issued OpenID Providers v2, which provides a redirection flow to an agent such as a native app or PWA app. This does look a bit different from traditional OpenID Connect though, as each End-user is effectively its own issuer with its own public key pair. Since the browser and platform will have integrated support for FIDO/WebAuthn tech, they may still provide a better experience for equivalent scenarios.
rasengan0 4y ago
Your phone or else? I already have a FIDO supported Yubikey, what if I don't have a phone? Or don't want to upgrade or use one in the future?
hitovst 4y ago
Can't say we weren't warned.
adhesive_wombat 4y ago
Since Teams can't even be bothered to get Yubikeys working on Ubuntu, I'll believe Microsoft when I see it.
_pdp_ 4y ago
Everyone forgets that the majority of people don't use password managers let alone FIDO/WebAuthn and similar technologies. It will take really, really long time to replace passwords.
_trackno5 4y ago
Has anyone found a link to the new specification draft? I'm wondering if the spec for the authenticator will be open so that anyone could build their own
NorwegianDude 4y ago
Imagine a world where Apple, Google and Microsoft allowed users to use whatever identity provider they wanted. You would select the provider you want, or be your own provider. Then you would be able to enable 2FA, use hardware keys and whatever else with ease and higher security. No more passwords, as the provider basically replaces a password manager. I wish something like OpenID will be the go to solution some day.
dyml 4y ago
Shameless plug: if anyone wants to try this out I built an API: https://www.passwordless.dev/ https://www.passwordless.dev/ (I’m also the creator and maintainer of fido2-net-lib)
aunterste 4y ago
until your FIDO key sits in a apple/Google/MS cloud account that has been disabled because of some alleged tos violation and you can't extract it from your phone. No thanks.
solarman5000 4y ago
Sounds good, but it makes me uneasy when these 3 companies agree on something. As far as I'm concerned, they are all working for the govt
infologics 4y ago
[dead]
internetter 4y ago
Thanks, I hate this. Basically, now we are entrusting the world's biggest companies to our logins with tight integration on OS level. What's worse is these keys will be stored in the "cloud", likely on proprietary server, using proprietary syncing. Only way this is not shit is if somehow they allow third parties in, letting users choose a default "authenticater" app, like bitwarden. Otherwise nothing is fixed and everything is bullshit. Hope they get regulated to hell and back.
musicale 4y ago
So does this mean every web site and app will no longer demand a mobile phone number for "security" or "verification" purposes? (usually verifying that data brokers can identify you by phone number, and that you can be sent SMS spam with impunity)

426 points by KoftaBob 4y ago

Genuine question. What benefit does this FIDO system provide over my password manager? I've read the what is Fido page and what Fido does page. I don't get it. It seems like the device is a single point of failure.

mark_l_watson 4y ago

Does anyone here know what privacy/tracking issues are with this standard?

jeroenhd 4y ago
I haven't found any so far. Each account gets a new public/private key pair so accounts can't be traced back to each other. Usernames are optional and might even become a thing or the past, making username reuse less of an issue for linking accounts. It all depends on the sync method provided. If synchronisation isn't end-to-end protected, you're handing Apple/Google/Microsoft the keys to the kingdom which is pretty bad.
bachmeier 4y ago
It fully resolves all existing privacy and tracking issues. You will have no privacy and will be tracked all the time. Problem solved.
0daystock 4y ago
FIDO2 privacy is actually pretty good and well thought out. There's a theoretical risk of a website sending authentication challenges for two different accounts and having both assertions signed by the same credential, basically correlating those accounts together, but this is unlikely to weaken collective privacy at scale.
- RL_Quine 4y ago
  Kind of. Yubikeys intentionally have a very small number of devices signed with one CA key and then they produce a new CA key, so those devices do have a basically unique identifier.
  - 0daystock 4y ago
    Can you share any more information about that? Is this identifier shared as part of the FIDO2/U2F spec?
    - md_ 4y ago
      I think they're referring to attestation (https://fidoalliance.org/fido-technotes-the-truth-about-attestation/#:~:text=Making%20sure%20that%20attestation%20certificates%20are%20used%20across%20large%20batches%20of%20authenticators%20of%20the%20same%20model%20(100%2C000%2B)%20ensures%20that%20users%20can%E2%80%99t%20be%20tracked%20based%20on%20their%20attestation%20certificate https://fidoalliance.org/fido-technotes-the-truth-about-atte....), which requires that attestation certificates be shared with a minimum of 100,000 other devices in order to ensure they're not unique IDs. Maybe the parent misread the spec as saying a _maximum_ of 100,000? Or something?
      - dane-pgp 4y ago
        The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked. Also, the Alliance could decide to blacklist a manufacturer just because they haven't implemented some new policy (like requiring a DNA scan of the user) so you better make sure that you buy a device from one of the "too big to fail" providers.
        md_ 4y ago
        > The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked. 1. By what mechanism can they blacklist a device? A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust. But that's between you and the RP. Authentication doesn't "talk to" the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys, so I don't understand what you are talking about here. 2. The intention of the attestation, as I understand it, is to enable RPs to use attestation to limit authenticators to e.g. those that pass FIPS certification (or similar enterprisey requirements), not to ban a whole batch because one key is known to be compromised. That's crazy; can you point out where anyone other than you has ever proposed this? 3. DNA scan? What are you talking about? 4. This assertion you are making, while bizarre and wrong, is very different than the assertion the grandparent made ("Yubikeys intentionally have a very small number of devices signed with one CA key...so those devices do have a basically unique identifier"), which, while also wrong, is I think a genuine mistake and not a bad-faith argument.

rvz 4y ago

Not a great thing to see the big three once again, driving the standards here. You should be worried. But as long as the ridiculous SMS 2FA is removed or replaced by something better, then fine. But we'll see how this goes. From the web side of this standard, this also tells me that Mozilla has no influence anywhere and will be the last ones to implement this standard in Firefox. Oh dear.

theklr 4y ago
Both FIDO and W3C are neutral places for this. Mozilla being a part of W3C and FIDO will have a say. This is just a PR stunt that the tech journalists ate up. They’ve been working together to make this for the last two years, it’s just an announcement to accelerate the work on it.
jeroenhd 4y ago
Mozilla is a member (https://fidoalliance.org/members/ https://fidoalliance.org/members/), so I doubt they'll be the left to their own devices. They'll probably lack the manpower to implement the additions well (I mean, you can't even paste a URL to an IPv6 address in Firefox for Android, which is one of the most basic features of a browser), but then again they already have Firefox Sync and a working WebAuthn system.
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]

bcatanzaro 4y ago

This passwordless signin process sounds neat, but will it increase Google’s power to lock people out of things? I don’t understand why Google doesn’t have an ombudsman - consumers have no recourse when Google locks them out, and it seems the consequences of Google locking you out are ever increasing. I think we’re going to need legislation to force Google to make a proper appeals process.

moritonal 4y ago
At some point (unless you're an Android dev) you have to accept a bit of responsibility. If you use Gmail, Drive and Android and then decide to use Android as your preferred implementation of FIDO (when YubiKeys ect, exist) I struggle to see how if you're locked out it's not partially the consumer's fault. You choose to use Google, and can attest to the fact it's not that difficult not to.
ThunderSizzle 4y ago
Don't use Google Drive. Don't use Gmail. That solves half the horror stories already.
CyberRage 4y ago
how FIDO has anything to do with google in particular? log in with google is not FIDO authentication...
judge2020 4y ago
Google's power to lock people out of their website is already here with Oauth2. This standard is unrelated; it works by having the browser/device itself sync the virtual security keys[0], much in the same way they sync passwords currently. That's the only thing changing here, giving people the choice (and encouraging them) to sign in via "what you have" instead of "what you know", but along with that they want to alleviate the UX concerns of people not being ready to carry around a separate physical security key. 0: https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys https://developer.apple.com/documentation/authenticationserv...

jeroenhd 4y ago

I hope this cross device system will be cross platform, but I wouldn't be surprised if you could only choose between macOS/iOS, Chrome/Chrome, or Edge/Edge sync. Funnily enough, a system for signing web authentication requests from a mobile device is far from new: I've been using https://krypt.co/ https://krypt.co/ for years (though it's on the long road of sunsetting right now) and I hope that will last long enough for the new cross device standard to replace it.

sdfgdfgbsdfg 4y ago
It won't, at least not in the short term. For that to happen trusted platform modules would need an api to export a private key wrapped with a certificate signed by (none/one/all/a quorum) of members in the circle of trust and itself. This will need standardizing. Only apple has implemented it so far because it has total control of their ecosystem. I think for Windows and Chrome to work like this, they'll need to start requiring TPM vendors to implement this in their drivers, but I can't see it being cross compatible with the API in the apple TPM any time soon, especially because the circle of trust is now as weak as the weakest TPM, and it's a reputation risk for apple if a credential gets compromised because some non-apple device trusted by the user in an apple circle of trust got breached
- jeroenhd 4y ago
  I think the first iteration of this system will definitely receive the synced key material in RAM. It's possible that the TPM spec will be updated to allow for loading pre-encrypted data into the TPM store as a response to this. Alternatively, existing secure computing systems (SGX/TrustZone) can also be used to decrypt the synchronised key relatively securely.
  - sdfgdfgbsdfg 4y ago
    receiving synced key material in RAM significantly alters the threat model. Apple's current passkey implementation does not, at any point, handle unwrapped key material in the operating system. I expect all other implementations to follow.

missosoup 4y ago

So their vision of the future is that to do anything online, one MUST have a phone (ahem, portable wiretap)? And they're going to be keeping my secrets for me, for my own good? I'm not sure I'm down with any of that.

jeroenhd 4y ago
I doubt they'll do away with tools like smart cards or Yubikeys any time soon. Laptops and modern computers also contains a TPM so you don't necessarily need to have a phone for secrets storage. If push comes to shove, I'm sure someone will develop a lightweight Android emulation layer you can run in the cloud that pretends to be a phone enough that you can use it.
- dane-pgp 4y ago
  > Laptops and modern computers also contains a TPM The root of trust for which extends to who knows where, and you're not allowed to look at the source code or learn how it works because that would threaten Hollywood's profit margins. We're basically building a system of DRM for access to human beings, and making the whole world dependent on these unaccountable entities.
  - jeroenhd 4y ago
    TPMs allow for arbitrary key storage by the operating system. They're not necessary for DRM. In fact, I've wiped my TPM several times to upgrade the firmware and I've had no trouble playing DRM content whatsoever. Technologies like Intel's management engine and SGX or their AMD/Qualcom/Apple counterparts are definitely problematic for user freedom in the way they're implemented. However, the TPM system itself is quite neutral: usually, you can clear it from the UEFI, lock it with a password (though that might need to be done from the OS) leaving whatever hostile OS you may run unable to exert any control on the device whatsoever. I'm personally a big fan of technologies like TPMs and secure boot as long as they're user configurable. I want to be able to install my own keys and force the system to only boot operating systems of my choice. Secure boot with just the MS keys is quite silly and ever since that one version of Grub could be exploited it's basically useless; secure boot with user or enterprise keys can be an incredible tool for defence in depth, for example when visiting countries where border agents may try to gain access to your data without your permission or knowledge (China, USA, etc.). If I had my way, I'd use Coreboot together with Secure Boot, with encryption keys stored in a TPM, the transfer of which goes through an encrypted channel (a feature of TPM 2.0 that nobody uses) after unlocking it with a password. Sadly, most Linux OS developers have a grudge against these technologies because they're used by companies such as Microsoft and Apple to reduce user freedom on some of their devices.

deleted 4y ago

[deleted]

foobarian 4y ago

I feel like I woke up in some parallel universe where TCP/IP didn't take off and FidoNet ended up as the Internet.

chondl 4y ago
I had the same thought. Living in the past.

TIPSIO 4y ago

I’m sure people way smarter than me have this figured out, from the Google post: > When you sign into a website or app on your phone, you will simply unlock your phone — your account won’t need a password anymore. > Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone So if I was a dumb kid, I could login to my parents bank accounts (or more / worst) if my mom gave me her 4 digit phone password for games earlier?

amelius 4y ago
No, because it should be evident by now that a phone is a personal computer, not to be shared with other people.
- josteink 4y ago
  I can tell you don’t have kids ;)
- wlesieutre 4y ago
  And personal computers have supported multiple people with separated data and settings since what, the 1980s?
- jeroenhd 4y ago
  For you perhaps. Phones are shared more often than you think. And no, they don't use multi-account features built into modern mobile operating systems.
davidkhess 4y ago
Normal usage would require a reauthentication - i.e. FaceId or TouchId - to produce the passkey.
- kogus 4y ago
  Currently on the iPhone, if your FaceID or TouchID fail repeatedly, you have the option to type in the passcode, which grants the same access. I'm not sure if the same is true on Android. I think the more general point is that "able to unlock the phone" is not / should not be the same as "I have verified that this is you" for sensitive applications and information.

josteink 4y ago

That’s a whole lot of text saying “things will be simpler” on repeat, without specifying how things are going to be and why that is simpler. Anyone got a link to something less hand-wavey and more concrete?

davidkhess 4y ago

I think this is really great news and am glad to see FIDO move forward as I think it greatly increases account security. One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. OOB recovery with SMS or email is considered too weak and the main recommended alternatives are to maintain multiple authenticators (i.e. multiple copies of your passkeys), re-run onboarding processes for new users or just abandon the account. It's going to be interesting to see how those alternatives play out in real world situations.

jeroenhd 4y ago
Reading this announcement, the idea seems to be that FIDO keys will be synchronised across devices. That means you can lose your phone and still get access to your accounts from your desktop. You might even be able to get access by simply logging in to your Microsoft/Apple/Google account on a new device if they implement this system stupidly enough.
- davidkhess 4y ago
  Yes, these will be stored in cloud storage like iCloud Keychain. But I can go into my iCloud Keychain and delete individual passkeys - or I may have only one Apple device and then lose it. Or some malware clears out all of my iCloud Keychain.
microtonal 4y ago
One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. I think the idea is that passkeys are synced between devices, see e.g.: https://developer.apple.com/videos/play/wwdc2021/10106/ https://developer.apple.com/videos/play/wwdc2021/10106/ I haven't look deeply into passkey enough yet, but aren't we replacing "what if I lose by device" by "what if company XYZ decides to nuke my access to my synchronized passkey"?

photochemsyn 4y ago

Suggested edit of mission statement in the name of increased accuracy: “The standards developed by the FIDO Alliance and World Wide Web Consortium and being led in practice by these innovative companies is the type of forward-leaning thinking that will ultimately make the American people easier to track online. This will be done by linking all online activity to unique personal attributes, i.e. "their fingerprint or face, or a device PIN." It's basically another step towards the China model of total mass surveillance of the population. [edit: all the justifications for this proposal - aren't they mostly solved by the use of password managers?]

alberth 4y ago

Dumb question: why are biometrics being used to replace the password, shouldn't the biometric replace the username?

sph 4y ago
Sounds to be like we're replacing the username and the password, i.e. something you know with username and your phone, i.e. something you have. It sounds like it's still a one factor authentication system, but different.
- alberth 4y ago
  Follow-up dumb questions: - so what happens if you don't have your phone at time of login? - if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms? - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
  - maxfurman 4y ago
    If you don't have your phone, you can't log in. SMS 2FA has the same problem. You technically should be able to migrate from one provider to another, it remains to be seen how easy Apple and Google will make the process. That last one is a great question that I don't know the answer to.
    - judge2020 4y ago
      > You technically should be able to migrate from one provider to another, it remains to be seen how easy Apple and Google will make the process. On a UX level, the transfer to another syncing security key "provider" is going to be interesting, if they even do that at all - I kind of doubt they'll have a "transfer your iCloud passkeys to your Chrome password manager" and they'll instead say "go to each service and enroll a new security key via your new syncing key manager". On a technical level, I wholly imagine there'll be a tool that pulls iCloud Passkeys[0] via the MacOS Keychain application and then inserts them into your new key manager. 0: https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys https://developer.apple.com/documentation/authenticationserv...

throwaway52022 4y ago

I've resisted switching to a hardware key because I know that I'm going to break it, and that seems like a huge pain in the ass. I really want to be able to make a couple of backup keys, or maybe put another way, I want to be able to put the private key on the device myself, I don't necessarily care that the key is generated on the device and never leaves the device. I don't care if that slightly reduces my security - I'm not protecting nuclear weapons, my threat model is not state actors trying to attack me, my threat model is me leaving my key in my pants pocket before putting it in the washing machine.

vngzs 4y ago
You just register 2-3 keys. It's not so bad.
- georgyo 4y ago
  It's actually horrible! Even key rotation is horrible! My yubikey is getting to about 10 years old, and I have replacements for it but find it very difficult to switch. It will eventually fail as an things do and it will be problematic. The problem is that I have several dozen accounts connected to it and I don't know all of them. So either I'm carrying and trying multiple keys at all times or not getting into a site that haven't been rotated yet. Multiple keys on an all sites is also basically impossible. You need to register all the keys, and ideally those keys are in different places.
  - bpye 4y ago
    I’m going to need to work this out soon. I picked up a pair of new YubiKey 5Cs yesterday with their sale. I’ve been using a YubiKey Neo for years for U2F, TOTP and GPG. Moving the GPG key is easy - though I might try using the FIDO2 support in SSH instead. However for every TOTP and U2F key I’m going to have to re-enroll the new keys… It feels like there should be a better way.
    - bradstewart 4y ago
      It would indeed be nice if you could "cross sign", CA style, a new yubikey with an old one, and that would somehow get passed along to the various services. I have not thought about the various attack vectors that this may or may not enable though.

deleted 4y ago

[deleted]

Andrew_nenakhov 4y ago

Played with the Yubikeys a couple of days ago. Rather nice thingies that are very easy to lose somewhere.

0daystock 4y ago
It's reasonably safe to leave them connected to the devices you regularly authenticate from, unless your threat model includes an adversary willing to use physical attacks.
- oynqr 4y ago
  Unless you have some way of authenticating all of your hardware with the key, taking it with you still leaves plenty of options for a physical attacker.

criddell 4y ago

It seems like FIDO is going to win the race for the next generation authentication scheme. I was rooting for Steve Gibson’s SQRL.

davidkhess 4y ago
Last time I looked at SQRL, it had an unfixable man-in-the-middle problem. Though, general acceptance of QR Codes does seem to have finally taken off.

bedast 4y ago

The weakest link in security is always going to be humans. Account compromise is is more often a human problem than a technological one (spamming requests, password reuse, simple passwords, (spear) phishing, direct social engineering, etc). If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords. Easier to use. Easier to social engineer a compromise. I get regular requests to get into my Microsoft account using their new login form that sends a key code rather than prompting for password. "Passwordless" just means that prompt goes to an app where a user unlocks their device to approve the login. This seems like worse security, not better. I'm okay with an approval prompt if it's part of a multi-factor auth system. Not if it's the only auth.

j_san 4y ago
But isn't the "thing" about FIDO (or maybe just security keys?) that the domain is also integrated into the challenge the client/key has to solve? So from what I understand a attacker couldn't as easily fish me by pretending e.g. to be Google. With a password or even a TOTP code the attacker could just pose as Google and forward the credentials to the actual site.
- bedast 4y ago
  You're looking at an exploit from a technological point of view, which I expect this community is likely to do. Think of it from the perspective of the average user. I know for a fact if my mom was told by an attacker "if you see an approval request for your account, just accept it" she would do so. It's taken time to train her not to give anyone her password. I've read of attackers with valid passwords spamming logins in hopes to trick a user into approving the auth. Whether it's because it woke up the user and they're in a sleep fog, or they're busy and not paying attention. Microsoft, at some point, changed their login flow so that, by default, when you enter your username, it sends a pin. I receive regular attempts at this. This isn't going to work out for the attacker because they have to get the pin. But if all that's required is a button press, the attacker could just make the login request and wait. With multi-factor auth, where a password is in use, you have to get past the password before getting to that auth approval. It reduces how much noise the user gets and the chances of success for the attacker.

danijelb 4y ago

I'm glad to see that the tech industry seems to be re-learning that creating and adopting interoperable standards is a way to go

throwaway52022 4y ago

I don't trust Google or Apple to be my main authentication provider, or to manage syncing my private key. Their customer service is terrible and they are way too arbitrary on locking folks out. I would trust my bank (well, my credit union.) I can go see them in person if I need to and they take my lawyer seriously, they also take security seriously, they're properly regulated, and ultimately they're my main concern if someone stole my credentials, so I'd like them to be on the hook for protecting my credentials.

0daystock 4y ago
This announcement isn't about that and neither provider is asking to sync your private key. In fact the opposite is true: with FIDO2, you're in much greater control of your account security because authentication creds are now on a hardware token versus as bearer credentials you type and an adversary can steal and replay. Many of us believe we're very good at protecting our passwords, but this isn't true in reality and FIDO2/U2F standards objectively make accounts more secure precisely because they remove humans from the equation.
- throwaway52022 4y ago
  Except it kind of is - the way I read this is "Apple/Google will turn your phone into a hardware FIDO token, but will use iCloud/whatever to reduce the huge painpoint of having more than one hardware token and keeping them all in sync" I really love the idea of FIDO and making sure that my authenticator only authenticates to sites that I've approved, but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future.
  - toomuchtodo 4y ago
    Your average user is more concerned about losing their password than they are about authenticator sovereignty. Moving towards cryptographic primitives for auth versus shared secrets is a net benefit versus current state. > but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future. Compromise is necessary, and probably a bit of regulation from government to enforce good outcomes from exception handling. Passkeys need to be stored and managed somehow, and your average user does not want to do that, just like they don't want to run their own mail server, syncthing instance, or mastodon instance. EDIT: (HN throttling, can't reply) @signal11 You can already be locked out of all of those accounts without recourse.

oversocialized 4y ago

kragen 4y ago

Jeez, I hope they don't expect us to put them in charge of the nodelist for Zone 1.

brightball 4y ago

Finally! Assume every password for every user on your site has been leaked. What now? This dramatically reduces the potential exposure to phishing and password leaks.

WaitWaitWha 4y ago

I like the idea, but not sure about the implementation. What happens when there is an outage at Google or Apple? What happens when I lose/get stolen/break/change my cell phone? What happens if I do not have/want a cell phone?

pionar 4y ago
> What happens if I do not have/want a cell phone? WebAuthn works with hardware tokens, so something like a Yubikey will also work.
judge2020 4y ago
The FIDO Standard talked about here includes regular security keys, so, if you don't want to use passkey, you can get a physical security key; and while I imagine the push for passwordless will be large, I doubt they'll completely remove passwords anytime soon.

mordae 4y ago

LOL, I was expecting the title to continue "... Fraud, According to $EU_COUNTRY Government". Seems like I don't trust them.

earthboundkid 4y ago

Aw yeah, BBSes are back baby! One question, who is going to pay for all the long distance calls?

deleted 4y ago
[deleted]

stjohnswarts 4y ago

no thanks. I don't want one account that apple/google/whoever can revoke and ruin my online life. fuck that. I'll take my chances with 2FA and passwords. When it finally gets breached (if you haven't been cancelled!) imagine how much one online cracker will able to do. This also allows them unlimited access to follow you all around and see what you do, where you log in, etc.

_trackno5 4y ago
> I don't want one account that apple/google/whoever can revoke and ruin my online life What are you even going on about? As long as you have access to your FIDO authenticator, you'll still be able to use it regardless of what they do with your account.
deleted 4y ago
[deleted]

aftbit 4y ago

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.

zozbot234 4y ago
Is this actually needed? Looks like the online part of this is just WebAuthn, which could be supported by the same tools we use for TOTP. You would "enroll" a visible master secret that you could then back up and optionally store in a hardware security key. The device itself wouldn't need to allow for extracting the secret again, because you backed it up at enrollment.
- lrvick 4y ago
  Ledger and similar hardware wallets support one time BIP39 backup covering all current and future accounts today.
jupp0r 4y ago
Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.
- jedberg 4y ago
  While it's not a bad idea, I'm pretty sure Yubikey recommends a backup key so that they can sell twice as many Yubikeys.
- Zamicol 4y ago
  "providers allow you to register multiple keys" Why isn't my identity just a Merkle root? I don't understand the need to register individual keys.
  - giaour 4y ago

mrkramer 4y ago

I never understood why TLS Client Authentication[0] is not used more because that way all other standards including FIDO wouldn't be needed. [0] https://blog.cloudflare.com/introducing-tls-client-auth/ https://blog.cloudflare.com/introducing-tls-client-auth/

jedberg 4y ago
It's the classic key distribution problem. You'd have to get client certificates to people securely. It works for corporations because they can send you a device with the client cert pre-loaded.
- NovemberWhiskey 4y ago
  Firstly, PKI generally doesn't have a key distribution problem because keys never get distributed; they get generated in-place, certificate signing requests are sent to certificate authorities, certificates are signed and returned. Secondly, in the TOFU model that applies to WebAuthn, you don't even need to have a certificate authority - you can self-sign. The problem is really, as alluded to another comment, that if you share a single certificate across multiple sites then you are sharing a common tracking id between them (e.g. your certificate fingerprint). Logout is also a user experience pain point unless the certificates are stored on e.g. a smart card that can be removed.
zozbot234 4y ago
Client certificates have privacy concerns when used with ordinary web sites, as opposed to the API requests assumed in that blogpost. WebAuthn provides a tweaked featureset that addresses these concerns.
NovemberWhiskey 4y ago
Within the DoD, it's ubiquitous. see https://en.wikipedia.org/wiki/Common_Access_Card https://en.wikipedia.org/wiki/Common_Access_Card

lizardactivist 4y ago

FIDO also enables great opportunities for tracking. But we're not supposed to talk about that.

md_ 4y ago
Hmm, what opportunities? Genuinely curious what you mean here.
- aaaaaaaaata 4y ago
  If you use the same public keypair across many unrelated sites, an observer could blah blah blah
  - md_ 4y ago
    Nope. See SG-4: https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-security-ref-ps-20141009.html https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fid....

eulers_secret 4y ago

Is there any way to use this system without an extra device (no phone, no key, only my pc)? If not, is there a FOSS implementation of these required new devices? Maybe an emulator for one? Can I download an manage my own keys, manually? Can I self-host the authentication layers so I don’t need to use a 3rd party?

sjustinas 4y ago
> Is there any way to use this system without an extra device (no phone, no key, only my pc)? I've used rust-u2f in the past, although it seems to be Linux only. https://github.com/danstiner/rust-u2f https://github.com/danstiner/rust-u2f
- eulers_secret 4y ago
  Thanks, I’ll check it out! Looks like it answers some of my concerns. Super cool!

beefee 4y ago

I fear services will force the use of certain devices, like those on the FIDO certified products list [0]. Will there be a way to use open hardware, open firmware, and user-controlled hardware attestation keys? Or will that be considered a fraud/bot risk? [0] https://fidoalliance.org/certification/fido-certified-products/ https://fidoalliance.org/certification/fido-certified-produc...

RandyRanderson 4y ago

Saved you a goog and pop-over: "FIDO ... is an open industry association ... whose stated mission is to ... help reduce the world’s over-reliance on passwords" https://en.wikipedia.org/wiki/FIDO_Alliance https://en.wikipedia.org/wiki/FIDO_Alliance

fmakunbound 4y ago

Reading through the threads here: If the HN can't articulate FIDO and differences between it and the now decades old password model to each other, I think regular jack-offs are going to have trouble. People have the mental model that their secret is stored in their gray matter/post-it note/password manager, and now you're telling them it's in their phone, and somewhat related to the phone's security model, or maybe a "yubikey", or behind biometrics, or maybe not, it depends, and Big Co. has copy, of something, and it's synced, and one possibly "migrates" between Big Co. and Big Co. might deliberately/accidentally disable all your websites, or losing your device/yubikey/piece of paper means you're screwed, possibly...

deleted 4y ago
[deleted]
toxik 4y ago
Unrelated to what you wrote, but it is actually jagoff or jag-off. It is not related to jacking off.
deleted 4y ago
[deleted]
stavros 4y ago
FIDO is an authentication standard. It doesn't care where your secrets are, it just mandates a way to use them to log in to websites. You can still use a password manager, it will just basically contain a single encryption key for all sites.
rad88 4y ago
Yeah, well what I want is a (physical, literal) membership card like I have at the gym or library. I think "regular" people can learn to use USB tokens, and that they might make more intuitive sense than passwords. These places don't challenge me for the "secret password" when I come in, I just present or scan my card. It's very tricky obviously, in terms of engineering and operations, for an internet based company to arrange anything similar. But I don't think it's too mentally foreign for the user (assuming we develop good standards). So cards make sense to me. Way more sense than passwords. Maybe someone else feels more comfortable with the details living inside their phone, but that doesn't affect my mental model. Users don't need to understand or be taught the entire standard.

teeray 4y ago

Does this provide any benefit over a (properly used) password manager? I’d be happy with just: - an “alphabet”, “minlength” and “maxlength” attributes on password fields so password managers generate perfect passwords every time - a well-known URI for password managers to do zero-touch password rotation. - actual elements for login components to close the confused deputy attack for password managers. All these things would be much easier changes for crufty old sites to make, which would aid adoption.

yakak 4y ago
First you need to invent a password manager that can be properly used? The one I have runs on my computer and trusts everything else I've ever installed not to have put in a mechanism to observe memory allocated to my browser.
- teeray 4y ago
  Is that how most credentials are stolen these days?
  - Sahbak 4y ago
    Most attacks are social engineering. Everything else, to the best of my knowledge, does not target passwords
    - judge2020 4y ago
      The biggest attack is persistent login tokens that are stored on a device, eg. Discord has an issue with malware (disguised as DMs from random people asking "do you want to try out a beta for my game") that steals the login token from appdata, using it to purchase a bunch of gifted nitro and perpetuate the scam via that user's account.
  - raxxorraxor 4y ago
    Users opening shady attachments or going to amarzön.se and logging in are probably 99% of cases.

Animats 4y ago

Does this imply that every service you connect to knows your unique identity?

diffeomorphism 4y ago
No.
NovemberWhiskey 4y ago
No; each site to which you authenticate gets a separate, probabilistically unique credential id.
Mindless2112 4y ago
No, each registration generates a new key pair; but maybe: > The signature counter is a strictly monotonic counter and the intent is that a relying party can record the values and so notice if a private key has been duplicated, as the strictly-monotonic property will eventually be violated if multiple, independent copies of the key are used. > There are numerous problems with this, however. Firstly, recall that CTAP1 tokens have very little state in order to keep costs down. Because of that, all tokens that I’m aware of have a single, global counter shared by all keys created by the device. [...] This means that the value and growth rate of the counter is a trackable signal that’s transmitted to all sites that the token is used to login with. http://www.imperialviolet.org/2018/03/27/webauthn.html http://www.imperialviolet.org/2018/03/27/webauthn.html

CKMo 4y ago

This is a good step forward, I just hope they work on ensuring the end user experience for less technical people doesn't seem more complicated than passwords. It's a work in progress.

austinbv 4y ago

The problem with any key based auth or biometric auth is a user can be compelled by LEO to hand over private keys or open a biometric lock. Passwords are protected by the 5th amendment.

Rafert 4y ago
The actual exchange with the server is using public key cryptography. How you unlock the key material locally could be a number of ways: PIN, password, fingerprint scan, voice recognition, etc
la6472 4y ago
Why do we need another AuthN protocol? We should extend OIDC as needed instead of again trying to reinvent the wheel.
- bdamm 4y ago
  Because the interaction with the hardware authenticator is local. OIDC and WebAuthn can work together.
- drdaeman 4y ago
  In WebAuthn you're actually in possession of your own identity (or, to be more precise, your identity is established between you and website). In OpenID, OAuth and OpenID Connect the paradigm is completely different, where your identity is provided by someone else.
  - la6472 4y ago
    Yes I get that but I think OIDC could be extended to cover that too whereas the Authenticator or iDP is the local face scanner kr other biometric and then the rest ie exchange of token etc stays the same. That way there won’t be two completely separate path and that will defeat the purpose of SSO. And it looks like there are already some implementation of this https://www.bioid.com/facial-recognition-app/ https://www.bioid.com/facial-recognition-app/
deleted 4y ago

nekomorphism 4y ago

daenz 4y ago

It would be nice for Amazon to commit as well. AWS has support for only a single Yubikey, which is mostly useless, unless you don't care about being locked out of your account if you lose that one key.

aaaaaaaaata 4y ago
Yeah, they should be ashamed of themselves — forget losing it, what if it fails...? It's bad practice to register just one hardware key, if your service has no side-doors.
arianvanp 4y ago
They support multiple if you use AWS SSO instead of IAM directly though.

ChikkaChiChi 4y ago

Why aren't we doing more to validate the identity of the service we are trying to connect to? CAs don't allow me to establish my own personal web of trust. If I connect once to my bank in a method I deem safe, I should be able to store their credentials in an easy to validate way. That way if I fall for a phishing attack, the browser can CLEARLY indicate to me that I'm encountering a new entity, not one I have an established relationship with. Concurrently, OSes need to do a way better job of supporting two factor locally and out-of-the-box. To even use a yubikey personally you have to install their software and disable the existing login methods or else you can still login the original way you set up. While we're at it, browsers and operating systems should actually lock out the second a key is no longer connected/in range. I know smart cards can behave similarly, but this needs to be grandparents level of easy to set up and control. I would feel much safer with my elderly family having "car keys" to their PC.

Arnavion 4y ago
They closest thing to avoiding being phished by a different "secure" entity is that your password manager will refuse to autofill (*) your credentials. But it's true that this is far from sufficient - this kind of autofill is wonky and doesn't work with all pages, so users can get conditioned to working around it by manually copying and pasting from the password manager to the browser, which defeats the protection. Many users prefer to always copy-and-paste anyway, because that avoids having to install the password manager's corresponding browser addon which can seem more secure. (*): Note that "autofill" only means "automatically populate credentials", not "automatically populate credentials without any user interaction". Clicking the username field, choosing a credential from a dropdown that the password manager populated for you based on which credentials match the website in question, and then having it be applied is also "autofill".
- ChikkaChiChi 4y ago
  You're right, that's woefully insufficient. The authentication challenge should clearly (using color and text) whether or not the challenge is an established part of your trust network and the hardware token should be able to validate the authenticity of the challenge modal itself. Users should be able to take an action they trust, while at the same time having the choice of that action taken away (or made more cumbersome) if they are about to get themselves into trouble. There are people far smarter than me working on these problems, but I feel like they are so hyperfocused on state-security that they refuse to listen to anyone regarding actual usability.

EGreg 4y ago

Can I use the webauthn API to have the user confirm arbitrary actions or only authenticate? Like, what if I send a different challenge every time?

Ajedi32 4y ago

This is huge! It sounds like they're finally going implement cross-device synced credentials; a move I've been advocating now for the last two and a half years[1]. Widespread support for this feature is, in my opinion, the last thing needed to make WebAuthn viable as a complete replacement for passwords on the web. The white paper is here: https://media.fidoalliance.org/wp-content/uploads/2022/03/How-FIDO-Addresses-a-Full-Range-of-Use-Cases-March24.pdf https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... Seems like they announced this back in March and I missed it somehow. [1]: https://hn.algolia.com/?query=ajedi32%20webauthn&type=comment https://hn.algolia.com/?query=ajedi32%20webauthn&type=commen...

PostThisTooFast 4y ago
la6472 4y ago
I get that but I think OIDC could be extended to cover that too whereas the Authenticator or iDP is the local face scanner kr other biometric and then the rest ie exchange of token etc stays the same. That way there won’t be two completely separate path and that will defeat the purpose of SSO ie OIDC websites will authenticate with google or Facebook but FIDO enabled websites will work with face recognition. And it looks like there are already some implementation of this OIDC enabled face recognition https://www.bioid.com/facial-recognition-app/ https://www.bioid.com/facial-recognition-app/
- dwaite 4y ago
  1. You can use OpenID Connect as a protocol to integrate (via federation) with a site that provides authenticator management. This is AFAIK how most deployments work today - even if that OpenID Provider winds up being something you run or you pay to be run for you (AKA a CIAM solution). 2. There is an upcoming specification, Self-Issued OpenID Providers v2, which provides a redirection flow to an agent such as a native app or PWA app. This does look a bit different from traditional OpenID Connect though, as each End-user is effectively its own issuer with its own public key pair. Since the browser and platform will have integrated support for FIDO/WebAuthn tech, they may still provide a better experience for equivalent scenarios.

rasengan0 4y ago

Your phone or else? I already have a FIDO supported Yubikey, what if I don't have a phone? Or don't want to upgrade or use one in the future?

hitovst 4y ago

Can't say we weren't warned.

adhesive_wombat 4y ago

Since Teams can't even be bothered to get Yubikeys working on Ubuntu, I'll believe Microsoft when I see it.

_pdp_ 4y ago

Everyone forgets that the majority of people don't use password managers let alone FIDO/WebAuthn and similar technologies. It will take really, really long time to replace passwords.

_trackno5 4y ago

Has anyone found a link to the new specification draft? I'm wondering if the spec for the authenticator will be open so that anyone could build their own

NorwegianDude 4y ago

Imagine a world where Apple, Google and Microsoft allowed users to use whatever identity provider they wanted. You would select the provider you want, or be your own provider. Then you would be able to enable 2FA, use hardware keys and whatever else with ease and higher security. No more passwords, as the provider basically replaces a password manager. I wish something like OpenID will be the go to solution some day.

dyml 4y ago

Shameless plug: if anyone wants to try this out I built an API: https://www.passwordless.dev/ https://www.passwordless.dev/ (I’m also the creator and maintainer of fido2-net-lib)

aunterste 4y ago

until your FIDO key sits in a apple/Google/MS cloud account that has been disabled because of some alleged tos violation and you can't extract it from your phone. No thanks.

solarman5000 4y ago

Sounds good, but it makes me uneasy when these 3 companies agree on something. As far as I'm concerned, they are all working for the govt

infologics 4y ago

[dead]

internetter 4y ago

Thanks, I hate this. Basically, now we are entrusting the world's biggest companies to our logins with tight integration on OS level. What's worse is these keys will be stored in the "cloud", likely on proprietary server, using proprietary syncing. Only way this is not shit is if somehow they allow third parties in, letting users choose a default "authenticater" app, like bitwarden. Otherwise nothing is fixed and everything is bullshit. Hope they get regulated to hell and back.

musicale 4y ago

So does this mean every web site and app will no longer demand a mobile phone number for "security" or "verification" purposes? (usually verifying that data brokers can identify you by phone number, and that you can be sent SMS spam with impunity)