13 ms·

A Yubico FAQ about passkeys

121 points by Shank 4y ago

xoa 4y ago
It's great to see ending the insanity of symmetric authentication (with passwords) is finally, finally gathering momentum. It's been frustrating because there were various potential efforts going back to the 00s at least, I remember logging into some sites with client certs. Somehow though the right combination of UI and broad support never happened despite the endless ridiculousness of leaks due to inevitable server side compromise, and then ever more bandaids on top like adaptive hash functions and password managers. Really looking forward to the day of all that fading into an (admittedly very) long tail of legacy. One place I'm kind of sorry hasn't been on the forefront of adoption though and gets into gear soon is web UIs, which often control some pretty important stuff. We run things like OPNsense for firewall/gateway needs, TrueNAS, various controllers, hardware that these days has a web UI etc. With "internal" applications it's already a lot more acceptable to slap heavier access requirements on them, only exposing them via VPN, but it'd be nice to be able to require hardware bound passkeys (to use Yubico's terminology) for web auth (recovery can be done via console if ever required).
- jtaft 4y ago
  What’s your take on accessing systems accepting passkeys on a shared computer? Or if you lose access to your devices? I think exporting passkeys could be useful. I wonder what phishing attempts will look like.
  - judge2020 4y ago
    On a shared computer, caBLE (“scan a QR code on another device”)[0] is the intended solution, since it’s a temporary way to authenticate and doesn’t save access to the target computer or anything. 0: https://i1.wp.com/9to5google.com/wp-content/uploads/sites/4/2022/10/Android-Chrome-passkey-support-5.png?ssl=1 https://i1.wp.com/9to5google.com/wp-content/uploads/sites/4/...
  - xoa 4y ago
    >What’s your take on accessing systems accepting passkeys on a shared computer? Plugging a token into a shared system is superior to passwords as well. Easy, somewhat safer if the system is compromised vs any given password (since an attacker would only be able to perform an online hot attack, and only on things the user was also doing assuming touch is required), much safer and easier compared to a password manager. Externalizing authentication on a shared system into something owned by the user is a pure win IMO for those who need to use them, and if anything is a particular win in that case compared to those who get to use only their own computers. >Or if you lose access to your devices? There is no one answer to this and I'm sure UX will evolve over time. As I said, in many cases there is a natural fallback in the form of local access console, same as if somehow all SSH keys or the like were lost. Ideally in general everyone would have multiple tokens, with at least one serving as a backup. Alternatively or in addition, good old backup codes (printed keys, either whole or n-of-m splits) on paper are a reasonable choice in some cases IMO. Some places that have a personal connection may simply have an IRL fallback, ie., your employer would just have you go to IT, or your bank might have you go into a branch in person with ID for a reset. In the future, there could be optional hardware solutions that allowed backing up exclusively to another key. I don't see the problem though as much different, than having hundreds/thousands of passwords to deal with. >I wonder what phishing attempts will look like. Pure remote "phishing" as it currently exists just isn't going to be possible with hardware based keys. But online hot attacks still will be, so I'd expect that will be that path taken (though it'll be harder). Stuff like getting people to run programs or waiting for them to access something sensitive on a rooted system such that they do a completely legitimate authentication flow but then additional actions are performed using it. But that's far more limited a threat surface than right now, and also will have more tractable technical counters. Still an improvement. I guess for a while the other "phishing" that might linger will simply be trying to use the inevitable legacy workarounds that you yourself asked about. Backup codes could certainly be phished in principle, social engineering tech support that "so and so lost access to their devices!", etc. But I think that will fade in effectiveness as time goes on, so might as well get to it. At the end of the day, symmetric shared auth is just insanity and asymmetric is simply fundamentally superior.
  - cmdli 4y ago
    If you want a passkey manager that allows you to export credentials, I would like to plug my own solution, Bulwark Passkey (https://bulwark.id https://bulwark.id). It's open-source and lets you export your passkeys outside of the system, as well as sync them across multiple devices, much like a password manager.
account-5 4y ago
I will probably use passwords until I am forcibly unable to. I'm happy with my password manager. Tying login credentials to a hardware device that can easily be lost or stolen, and that (at least from my understanding) are hard to transfer to new devices seems like a risk I'm unwilling to take. And a step back. I'm not adverse to replacing passwords with public/private key cryptography, but I need to be in control of it (not some multinational org) and I don't want it tied to a single hardware device.
- JustSomeNobody 4y ago
  I have one of the old blue keys. Never found a good use for it. I don't have my keys with me at my desk, so I never put it on my keychain. So then it's just laying around and gets shuffled of the desk and into a drawer. Meanwhile, my phone is always near and bitwarden just works.
- goodoldneon 4y ago
  I have 2 yubikeys and always register them both. So if one is lost or broken then I still have another to log into sites. As for theft, if you’re using your yubikey as a 2nd factor then they still can’t log in because they don’t know your password. If you’re using your yubikey as both factors then it either has a PIN or biometrics, so the thief can’t log in. My main use for my yubikey is for SSH. I have PIN-protected SSH with a private key that can’t be exfiltrated
  - illiac786 4y ago
    But if you register both every time, it means you always carry both yubikeys with you, right? I hope you don’t have both on the same keyring, but if you carry both around, the resilience/redundancy of that setup is lacking in my view.
  - neatze 4y ago
    sudo, screen lock, luks, ssh, pgp, weblogins, keepass are all setup with yubikeys. I wish I could generate my own private fido key in similar way as pgp.
okhuman 4y ago
Check out AuthCompanion, a user management server that brings passkeys to your users and is pretty straightforward to setup. https://github.com/authcompanion/authcompanion2 https://github.com/authcompanion/authcompanion2
ryanklee 4y ago
I've tried multiple times to work YubiKeys into my workflow and failed each time. The key needs to be with me all the time from room to room, building to building, location to location, not get lost, from change of clothes to change of clothes, and not end up in the laundry, and this is hard, hard, hard. Who has managed to do this successfully and without losing their minds? I hate passwords and would love to complement them with better security factors than my phone alone or find a way to move away from them entirely, but YubiKeys et al do not seem consumer viable to me. And I've tried.
- sebzim4500 4y ago
  I just leave it on my keyring. Do you have a code to enter your building or something?
  - ryanklee 4y ago
    I don't need my YubiKey just at work. I need it with me all the time regardless of whether I am even wearing clothes.
    - FeistySkink 4y ago
      OK, I'll bite, where are you logging in naked? Some eyes wide shut situation?
      - ryanklee 4y ago
        Because in my day to day life wearing clothes is not a prerequisite for interacting with technology. I frequently exercise. This requires many showers and many changes of clothes. I walk around in the morning just wearing my boxers for the first hour of the day or the last hour of the night. This isn't exactly abnormal behavior. I always have my phone around but always having my phone plus always having my YubiKey is a step up in difficulty and not a linear one. Any successful auth solution better be prepared to solve such behavioral issues or they won't ever reach sufficient adoption levels.
wordlessecho 4y ago
It it still a problem that backup your passkeys for other platform. Android seems allow you to store passkeys in third-party provider in the future. (https://developers.google.com/identity/passkeys/supported-environments https://developers.google.com/identity/passkeys/supported-en...) On Apple you can only share passkey between the Apple devices. (https://developer.apple.com/videos/play/wwdc2022/10092/?time=374 https://developer.apple.com/videos/play/wwdc2022/10092/?time...) On Windows you cannot even manage your passkeys. But you can add multiple passkey for single account. It might confuse people that passkeys is design as "a password replacement" (https://fidoalliance.org/passkeys https://fidoalliance.org/passkeys) but it also can be a FIDO2 as additional authorization method. Once you setup the FIDO2 PIN for YubiKey, you have to enter the PIN every time at registering your key. Which makes me annoying and reset my YubiKey to delete the PIN. Although Windows, Android, iOS and macOS all implement the passkey. But Google and Apple account does not support passwordless login. Microsoft still using their own implement of passwordless login. Recently Apple announce that they will support to use hardware key for two-factor authorization. (https://www.apple.com/newsroom/2022/12/apple-advances-user-security-with-powerful-new-data-protections/ https://www.apple.com/newsroom/2022/12/apple-advances-user-s...) It looks like Apple have no interest at either passwordless login and supporting cross-platform passkey for Apple ID. In the specification, it provides multiple algorithm choices for website developers. (https://www.iana.org/assignments/cose/cose.xhtml#algorithms https://www.iana.org/assignments/cose/cose.xhtml#algorithms) But Android, iOS and macOS only support ES256. Newer Windows support ES256 and RS256. Older Windows only support RS256. EdDSA is only supported by YubiKey.
- dwaite 4y ago
  > It might confuse people that passkeys is design as "a password replacement" (https://fidoalliance.org/passkeys https://fidoalliance.org/passkeys) but it also can be a FIDO2 as additional authorization method. Once you setup the FIDO2 PIN for YubiKey, you have to enter the PIN every time at registering your key. Which makes me annoying and reset my YubiKey to delete the PIN. Passkeys are used to describe an alternative to passwords, and as such the term is used to indicate particular characteristics for the user (such as being a primary factor and supporting password-manager-style user experience). FIDO authenticators and the WebAuthn API can be used to support other scenarios, such as second-factor usage. They also may support additional extensions, or support supplying attestations. But if you wanted to say what a passkey is as a technically defined object, it is a multi-device (backup-capable) WebAuthN credential which is discoverable and supports user verification. Likewise, there are single-device passkeys, which are non-backup-capable WebAuthN credentials which are discoverable and support user verification. Yubikeys support creating such credentials, and thus support creating single-device passkeys. > It looks like Apple have no interest at either passwordless login and supporting cross-platform passkey for Apple ID. Apple is notorious for not talking about future plans; however, all of the companies you mentioned are likely going to implement this technology in an incremental fashion. For example, that Apple is rolling out support for authentication via FIDO security key fobs as an advanced security option does not preclude broader WebAuthn login support for web and native access to all Apple accounts in the future as an alternative. Advanced security modes are just easier, as they are advertised as having significant usability impact. There are just real issues here left to solve, for example authenticating to an account on an Apple TV unit, where neither USB nor NFC are generally available.
marban 4y ago
The whole new auth methods wave is basically the equivalent of USB-C for the average consumer. Maximum confusion right from the start. Great.
- brookst 4y ago
  Great analogy. Tech people love it because it’s better, and they understand the nuances and are used to having to think about things like 2D matrices of features. Normal people expect simplicity and consistency and are totally confused.
  - rainsford 4y ago
    Speaking as a tech person, I think usability matters (or at least should matter) to tech people too. Maybe I'm just getting old, but I increasingly find that having cool features or security improvements isn't enough to make me like a product and that well designed usability is itself a tech feature worth admiring. Most people like when technology is easy to use, but tech people can also appreciate when technology is a well designed complete package that makes it so the most people can benefit from the cool tech improvements. My favorite example here is Signal, which both significantly improved upon the security of previous solutions like PGP encrypted email and was a massive usability improvement such average people could take advantage of the security it offered. As a tech person, I appreciate the latter at least as much if not more than the former. Security keys check the first box, but I'm not sure they've got the usability thing down yet.
    - brookst 4y ago
      Oh, I agree. I recently purged my house of any USB-C cable that can’t charge my laptop. That means no long high speed cables. But knowing that power will always work is more important than maximizing transfer speeds for my applications.
- sebzim4500 4y ago
  From my experience, non tech people think USB-C is great but only because you can plug it in upside down.
amluto 4y ago
> But passkeys aren’t a new thing. It’s just a new name starting to be used for WebAuthn/FIDO2 credentials that enable fully passwordless experiences. These types of credentials are also called discoverable credentials, or sometimes resident credentials. Can someone explain what discoverable credentials have to do with a passwordless experience? Accepting a WebAuthn credential in lieu of a password is a policy decision and is every bit as possible with non-discoverable credentials. As I see it, discoverable credentials enable a usernameless experience, which is a rather different phenomenon.
- arianvanp 4y ago
  You are correct.
  - amluto 4y ago
    I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc? Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard.
    - dwaite 4y ago
      > I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc? An agent that registers non-discoverable credentials as discoverable ones via local storage is an option, although not one that browsers have yet chosen to support. This however locks you onto a browser (if it doesn't have a cloud sync fabric) or into a particular ecosystem (if that browser has a sync fabric). Authenticators support discoverability because a limitation of only being able to authenticate in a single browser is significant. Since authenticators tend to either support both discoverability and user verification, or neither discoverability nor user verification, I suspect there won't be business drivers to support such user agent storage/functionality. Note that the CredProtect extension protects discoverability of a resident credential without user verification, and Chrome requests this extension on sites' behalf by default. This protects against scenarios where a third party who gets physical access to your authenticator (thief, partner, law enforcement, border control) can introspect the websites you have accounts at without your participation. > Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard. There was a serious proposal: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension The challenge is that support for such things (new multisig algorithms, this recovery extension) require active relying party participation, and many would just choose not to take on the extra effort. So instead we have multi-device credentials, where there is a sync fabric behind the scenes. Nothing would preclude hardware credentials from participating in such a thing, although they would obviously need either radios or software assistance to do so. To capture the change in physical hardware, a new extension (devicePubKey) is being proposed under Web Authentication. This would have the benefit over the previous recoverability proposal in that sites opt-in to extra responsibility as needed for their business logic, compared to usability being restricted unless sites do extra work.
BoppreH 4y ago
I still see problems with recovery. You either have to (a) carry your primary and backup devices with you and risk losing both; (b) lower your security by using non-hardware-protected keys; or (c) be unable to create new accounts on-the-go. What I would like is a recovery key that I can store in a rarely-accessed safe. Here's an idea from an old paper of mine: on every sign up, you register not only your primary device, but also a recovery pair made of [hash(recovery_token), encrypt(master_public_key, recovery_token)]. Then you keep your single master_private_key in a safe. If you ever lose your primary device, you then: 1. Take your master_private_key from the safe (e.g., printed QR code, backup device, passphrase for key derivation, etc). 2. Ask the service for your encrypted recovery_token and decrypt it with your master_private_key. 3. Ask the service to reset your credentials and use the recovery_token as authentication, to be checked against the expected hash. This way you can create recoverable accounts without carrying your backup key, without downgrading to non-hardware security, without giving personal information like email address for out-of-band resets, and without creating a backup that has to be updated. As a bonus, you can use hash(master_public_key || service_domain) as username for anonymity without extra storage. And this process also works to recover compromised accounts, something you don't get with two Yubikeys that can remove each other.
- sebk 4y ago
  Your idea is not very different from this proposed spec also defined by Yubico: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys.
  - BoppreH 4y ago
    > Your idea is not very different from this proposed spec also defined by Yubico: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension Good point, in that they are both based on backup credentials generated on-demand. But the Yubico scheme is a lot more complicated and limited to backup devices (as opposed to passphrase or printed QR code). On the other hand, the signed handover is really cool, and doesn't require the server to store encrypted data like in mine. > In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys. I agree completely.
crote 4y ago
I am very bearish about the current push to passkeys. To start with, why throw out the password? We have literally spend a decade getting people to use 2FA - and rightfully so. Why would we suddenly voluntarily compromise security and go back to 1FA? Sure, people suck at passwords, but even a poor password combined with an authenticator would be better than solely an authenticator. I am quite worried that websites will adopt this form of 1FA as the "new normal", compromising the security of anyone who still wishes to use secure passwords. Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature, but meanwhile vendors only allow syncing between their own devices. This makes a multi-vendor environment extremely challenging to use, not to mention that switching to another vendor risks losing access to a lot of websites. And that's even ignoring the possibility of a vendor getting mad at you and deciding to nuke your account - and all the passkeys with it. Until there is a proper (open!) standard for exporting and importing passkeys, this is an unacceptable risk to me. Some of this could be mitigated by a universal pluggable passkeys backend, but I am not really seeing any substantial movement in this direction. To me, it looks like Google/Apple are trying to replace "Log in with Google/Apple" with "Log in with Passkeys" to make it seem like it is an open platform, while still locking it down as tightly as possible. Despite being an open standard, the implementations are anything but. Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop. I am also seeing a lot of misleading statements surrounding its security. For example, the claims that the keys are stored in a TPM/Secure Enclave. Meanwhile, in practice the TPM is only used for the local encryption of a copy of your passkeys. They also happily live on the cloud because they are being synced, and the vendors seem to be offering ways to recover them without access to a single device. They seem to be intentionally reusing language traditionally reserved for security implementations where the private key is stored solely in a HSM with no way to export it, but that is not at all what is happening here. Security-wise, it's nothing more than a rebranded cloud-synced password vault. Meanwhile, hardware token vendors like Yubikey point this out, but they do not see it as a threat as they are selling this synced implementation as not suitable for high-security environments - and rightly so. Luckily, the protocol has a built-in way to bypass this: the passkey backend can be asked for attestation, which in essence is an immutable certificate embedded in the hardware key, signed by the hardware vendor. If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course. By hopping on the Passkeys bandwagon, they are able to erect significant barriers to entry for any potential competitors. Finally, Passkeys provide a privacy risk. With traditional Webauthn the user provides a username to the server, and the server responds with a set of opaque blobs which the user's tokens use for further bidirectional authorization. With Passkeys, the server asks the token for their set of domain-relevant passkeys, which include the username. This is required for the intended single-click usernameless login, but the flip side is that an attacker would be able to discover all of your accounts by probing the token. Alternatively, the server would be able to discover an association between multiple accounts of the same person, destroying attempts to retain an anonymous alt account. All in all, to me Passkeys looks like a thinly-veiled attempt to lock users into certain ecosystems, using convenience as a carrot-on-a-stick. Meanwhile, it adds significant security and privacy risks while claiming to be more secure. Seeing this being touted as a "more secure password replacement" by such major players makes me weep for the future.
simonjgreen 4y ago
What I see here is Yubico pushing for continued relevance while vendors, such as Microsoft and Apple, move to hybrid software hardware solutions with greater recoverability and without having to carry another piece of hardware with you. I applaud Yubico for what they've done over the years championing hardware multifactor, improved awareness of multifactor, and further in standards and acceptance. However, unless they pivot their model towards the OEM market and start selling there chips to phone manufacturers, I can't see them ever hitting the mainstream. Both Windows Hello and Microsoft Authenticator (in passwordless mode) are brilliant examples of passwordless done in a secure way that is also incredibly user friendly to both use and set up.
- dwaite 4y ago
  > What I see here is Yubico pushing for continued relevance while vendors, such as Microsoft and Apple, move to hybrid software hardware solutions with greater recoverability and without having to carry another piece of hardware with you. I applaud Yubico for what they've done over the years championing hardware multifactor, improved awareness of multifactor, and further in standards and acceptance. One important aspect is that Web Authentication is an abstraction API for talking to an authenticator. The authenticators themselves can have wildly different policy/characteristics. Apple in particular is pushing exclusively toward the consumer space requirements with their current implementation of Passkeys, solely as a more secure password replacement. This means that clone ability and sharability are fundamental concepts for them, which currently go against business and regulatory requirements in several spaces. Since mandating creation of hardware-bound credentials goes against consumer usability, there isn't a clear path toward supporting them outside enterprise enablement via MDM. Android's current plans are to only support hardware-bound credentials for second-factor usage, not for passwordless usage. Microsoft will likely allow for user choice as to whether a credential is hardware-bound. I'm not aware if they will allow the relying party to dictate a requirement here. Yubico meanwhile has a FIPS-certified key, and has been pushing toward support at higher assurance levels per NIST 800-63. While additional hardware is annoying for users, to the business it amounts to a per-seat cost to solve a real problem. > However, unless they pivot their model towards the OEM market and start selling there chips to phone manufacturers, I can't see them ever hitting the mainstream. They have an interesting model in that, while a business may need a user to have a Yubikey or similar authenticator, there often isn't a requirement that they have one specifically provisioned and shipped by the business. I've seen environments where key fobs are provisioned to users primarily through Amazon. So I suspect Yubikeys will settle into a business user and prosumer space, but no the chance of widespread consumer adoption was always slim. The broader adoption of WebAuthn gets however, the more opportunities I think Yubico will have to sell into the gaps. [Disclaimers: WebAuthn WG member, FIDO 2 TWG vice-chair]
butz 4y ago
Could anyone comment on recovery options? If Yubikey, smartphone or computer breaks, how do I login?
- cuu508 4y ago
  You use your second key.
cmdli 4y ago
To those who are interested in passkeys but are worried about vendor lock-in and lack of control, I would like to plug my solution, Bulwark Passkey (https://bulwark.id https://bulwark.id). It's an open source passkey manager that allows you to export your credentials outside the system, giving you more control. I think passkeys have a lot of potential to improve security and ease-of-use (passwords are broken!), but we need to maintain users' control over their data if that is going to happen.
fmajid 4y ago
If a passkey can be cloned via cloud authentication, it can also be cloned when a government compels the cloud service to "authenticate" your friendly neighborhood secret policeman as being you. That in itself is a good reason to only use uncloneable credentials like a Yubikey for sensitive uses.
- TacticalCoder 4y ago
  > That in itself is a good reason to only use uncloneable credentials like a Yubikey for sensitive uses. Yup I really don't get this. For once we had something that made sense: an actual 2FA which required an actual physical device. And now with the alliance between Microsoft (which we know can always be trusted), Google an Apple the 2FA not only is becoming "1FA" (because the goal is to use the passkey instead of the password, not in addition to it). But transforming the 2FA to 1FA is not enough: we cannot let these secure hardware module make live hard for law enforcement (uh, sorry, for bad guys) so instead of having "no device, no login" we get instead "copyable passkey". "1FA copyable passkey" What a concept. Somehow I feel this isn't exactly going forward security wise. Then people will say: "but it's easy. but it's convenient. And moreover it's pushed by our beloved Microsoft!". Yup, exactly.

121 points by Shank 4y ago

xoa 4y ago

It's great to see ending the insanity of symmetric authentication (with passwords) is finally, finally gathering momentum. It's been frustrating because there were various potential efforts going back to the 00s at least, I remember logging into some sites with client certs. Somehow though the right combination of UI and broad support never happened despite the endless ridiculousness of leaks due to inevitable server side compromise, and then ever more bandaids on top like adaptive hash functions and password managers. Really looking forward to the day of all that fading into an (admittedly very) long tail of legacy. One place I'm kind of sorry hasn't been on the forefront of adoption though and gets into gear soon is web UIs, which often control some pretty important stuff. We run things like OPNsense for firewall/gateway needs, TrueNAS, various controllers, hardware that these days has a web UI etc. With "internal" applications it's already a lot more acceptable to slap heavier access requirements on them, only exposing them via VPN, but it'd be nice to be able to require hardware bound passkeys (to use Yubico's terminology) for web auth (recovery can be done via console if ever required).

jtaft 4y ago
What’s your take on accessing systems accepting passkeys on a shared computer? Or if you lose access to your devices? I think exporting passkeys could be useful. I wonder what phishing attempts will look like.
- judge2020 4y ago
  On a shared computer, caBLE (“scan a QR code on another device”)[0] is the intended solution, since it’s a temporary way to authenticate and doesn’t save access to the target computer or anything. 0: https://i1.wp.com/9to5google.com/wp-content/uploads/sites/4/2022/10/Android-Chrome-passkey-support-5.png?ssl=1 https://i1.wp.com/9to5google.com/wp-content/uploads/sites/4/...
- xoa 4y ago
  >What’s your take on accessing systems accepting passkeys on a shared computer? Plugging a token into a shared system is superior to passwords as well. Easy, somewhat safer if the system is compromised vs any given password (since an attacker would only be able to perform an online hot attack, and only on things the user was also doing assuming touch is required), much safer and easier compared to a password manager. Externalizing authentication on a shared system into something owned by the user is a pure win IMO for those who need to use them, and if anything is a particular win in that case compared to those who get to use only their own computers. >Or if you lose access to your devices? There is no one answer to this and I'm sure UX will evolve over time. As I said, in many cases there is a natural fallback in the form of local access console, same as if somehow all SSH keys or the like were lost. Ideally in general everyone would have multiple tokens, with at least one serving as a backup. Alternatively or in addition, good old backup codes (printed keys, either whole or n-of-m splits) on paper are a reasonable choice in some cases IMO. Some places that have a personal connection may simply have an IRL fallback, ie., your employer would just have you go to IT, or your bank might have you go into a branch in person with ID for a reset. In the future, there could be optional hardware solutions that allowed backing up exclusively to another key. I don't see the problem though as much different, than having hundreds/thousands of passwords to deal with. >I wonder what phishing attempts will look like. Pure remote "phishing" as it currently exists just isn't going to be possible with hardware based keys. But online hot attacks still will be, so I'd expect that will be that path taken (though it'll be harder). Stuff like getting people to run programs or waiting for them to access something sensitive on a rooted system such that they do a completely legitimate authentication flow but then additional actions are performed using it. But that's far more limited a threat surface than right now, and also will have more tractable technical counters. Still an improvement. I guess for a while the other "phishing" that might linger will simply be trying to use the inevitable legacy workarounds that you yourself asked about. Backup codes could certainly be phished in principle, social engineering tech support that "so and so lost access to their devices!", etc. But I think that will fade in effectiveness as time goes on, so might as well get to it. At the end of the day, symmetric shared auth is just insanity and asymmetric is simply fundamentally superior.
- cmdli 4y ago
  If you want a passkey manager that allows you to export credentials, I would like to plug my own solution, Bulwark Passkey (https://bulwark.id https://bulwark.id). It's open-source and lets you export your passkeys outside of the system, as well as sync them across multiple devices, much like a password manager.

account-5 4y ago

I will probably use passwords until I am forcibly unable to. I'm happy with my password manager. Tying login credentials to a hardware device that can easily be lost or stolen, and that (at least from my understanding) are hard to transfer to new devices seems like a risk I'm unwilling to take. And a step back. I'm not adverse to replacing passwords with public/private key cryptography, but I need to be in control of it (not some multinational org) and I don't want it tied to a single hardware device.

JustSomeNobody 4y ago
I have one of the old blue keys. Never found a good use for it. I don't have my keys with me at my desk, so I never put it on my keychain. So then it's just laying around and gets shuffled of the desk and into a drawer. Meanwhile, my phone is always near and bitwarden just works.
goodoldneon 4y ago
I have 2 yubikeys and always register them both. So if one is lost or broken then I still have another to log into sites. As for theft, if you’re using your yubikey as a 2nd factor then they still can’t log in because they don’t know your password. If you’re using your yubikey as both factors then it either has a PIN or biometrics, so the thief can’t log in. My main use for my yubikey is for SSH. I have PIN-protected SSH with a private key that can’t be exfiltrated
- illiac786 4y ago
  But if you register both every time, it means you always carry both yubikeys with you, right? I hope you don’t have both on the same keyring, but if you carry both around, the resilience/redundancy of that setup is lacking in my view.
- neatze 4y ago
  sudo, screen lock, luks, ssh, pgp, weblogins, keepass are all setup with yubikeys. I wish I could generate my own private fido key in similar way as pgp.

okhuman 4y ago

Check out AuthCompanion, a user management server that brings passkeys to your users and is pretty straightforward to setup. https://github.com/authcompanion/authcompanion2 https://github.com/authcompanion/authcompanion2

ryanklee 4y ago

I've tried multiple times to work YubiKeys into my workflow and failed each time. The key needs to be with me all the time from room to room, building to building, location to location, not get lost, from change of clothes to change of clothes, and not end up in the laundry, and this is hard, hard, hard. Who has managed to do this successfully and without losing their minds? I hate passwords and would love to complement them with better security factors than my phone alone or find a way to move away from them entirely, but YubiKeys et al do not seem consumer viable to me. And I've tried.

sebzim4500 4y ago
I just leave it on my keyring. Do you have a code to enter your building or something?
- ryanklee 4y ago
  I don't need my YubiKey just at work. I need it with me all the time regardless of whether I am even wearing clothes.
  - FeistySkink 4y ago
    OK, I'll bite, where are you logging in naked? Some eyes wide shut situation?
    - ryanklee 4y ago
      Because in my day to day life wearing clothes is not a prerequisite for interacting with technology. I frequently exercise. This requires many showers and many changes of clothes. I walk around in the morning just wearing my boxers for the first hour of the day or the last hour of the night. This isn't exactly abnormal behavior. I always have my phone around but always having my phone plus always having my YubiKey is a step up in difficulty and not a linear one. Any successful auth solution better be prepared to solve such behavioral issues or they won't ever reach sufficient adoption levels.

wordlessecho 4y ago

It it still a problem that backup your passkeys for other platform. Android seems allow you to store passkeys in third-party provider in the future. (https://developers.google.com/identity/passkeys/supported-environments https://developers.google.com/identity/passkeys/supported-en...) On Apple you can only share passkey between the Apple devices. (https://developer.apple.com/videos/play/wwdc2022/10092/?time=374 https://developer.apple.com/videos/play/wwdc2022/10092/?time...) On Windows you cannot even manage your passkeys. But you can add multiple passkey for single account. It might confuse people that passkeys is design as "a password replacement" (https://fidoalliance.org/passkeys https://fidoalliance.org/passkeys) but it also can be a FIDO2 as additional authorization method. Once you setup the FIDO2 PIN for YubiKey, you have to enter the PIN every time at registering your key. Which makes me annoying and reset my YubiKey to delete the PIN. Although Windows, Android, iOS and macOS all implement the passkey. But Google and Apple account does not support passwordless login. Microsoft still using their own implement of passwordless login. Recently Apple announce that they will support to use hardware key for two-factor authorization. (https://www.apple.com/newsroom/2022/12/apple-advances-user-security-with-powerful-new-data-protections/ https://www.apple.com/newsroom/2022/12/apple-advances-user-s...) It looks like Apple have no interest at either passwordless login and supporting cross-platform passkey for Apple ID. In the specification, it provides multiple algorithm choices for website developers. (https://www.iana.org/assignments/cose/cose.xhtml#algorithms https://www.iana.org/assignments/cose/cose.xhtml#algorithms) But Android, iOS and macOS only support ES256. Newer Windows support ES256 and RS256. Older Windows only support RS256. EdDSA is only supported by YubiKey.

dwaite 4y ago
> It might confuse people that passkeys is design as "a password replacement" (https://fidoalliance.org/passkeys https://fidoalliance.org/passkeys) but it also can be a FIDO2 as additional authorization method. Once you setup the FIDO2 PIN for YubiKey, you have to enter the PIN every time at registering your key. Which makes me annoying and reset my YubiKey to delete the PIN. Passkeys are used to describe an alternative to passwords, and as such the term is used to indicate particular characteristics for the user (such as being a primary factor and supporting password-manager-style user experience). FIDO authenticators and the WebAuthn API can be used to support other scenarios, such as second-factor usage. They also may support additional extensions, or support supplying attestations. But if you wanted to say what a passkey is as a technically defined object, it is a multi-device (backup-capable) WebAuthN credential which is discoverable and supports user verification. Likewise, there are single-device passkeys, which are non-backup-capable WebAuthN credentials which are discoverable and support user verification. Yubikeys support creating such credentials, and thus support creating single-device passkeys. > It looks like Apple have no interest at either passwordless login and supporting cross-platform passkey for Apple ID. Apple is notorious for not talking about future plans; however, all of the companies you mentioned are likely going to implement this technology in an incremental fashion. For example, that Apple is rolling out support for authentication via FIDO security key fobs as an advanced security option does not preclude broader WebAuthn login support for web and native access to all Apple accounts in the future as an alternative. Advanced security modes are just easier, as they are advertised as having significant usability impact. There are just real issues here left to solve, for example authenticating to an account on an Apple TV unit, where neither USB nor NFC are generally available.

marban 4y ago

The whole new auth methods wave is basically the equivalent of USB-C for the average consumer. Maximum confusion right from the start. Great.

brookst 4y ago
Great analogy. Tech people love it because it’s better, and they understand the nuances and are used to having to think about things like 2D matrices of features. Normal people expect simplicity and consistency and are totally confused.
- rainsford 4y ago
  Speaking as a tech person, I think usability matters (or at least should matter) to tech people too. Maybe I'm just getting old, but I increasingly find that having cool features or security improvements isn't enough to make me like a product and that well designed usability is itself a tech feature worth admiring. Most people like when technology is easy to use, but tech people can also appreciate when technology is a well designed complete package that makes it so the most people can benefit from the cool tech improvements. My favorite example here is Signal, which both significantly improved upon the security of previous solutions like PGP encrypted email and was a massive usability improvement such average people could take advantage of the security it offered. As a tech person, I appreciate the latter at least as much if not more than the former. Security keys check the first box, but I'm not sure they've got the usability thing down yet.
  - brookst 4y ago
    Oh, I agree. I recently purged my house of any USB-C cable that can’t charge my laptop. That means no long high speed cables. But knowing that power will always work is more important than maximizing transfer speeds for my applications.
sebzim4500 4y ago
From my experience, non tech people think USB-C is great but only because you can plug it in upside down.

amluto 4y ago

> But passkeys aren’t a new thing. It’s just a new name starting to be used for WebAuthn/FIDO2 credentials that enable fully passwordless experiences. These types of credentials are also called discoverable credentials, or sometimes resident credentials. Can someone explain what discoverable credentials have to do with a passwordless experience? Accepting a WebAuthn credential in lieu of a password is a policy decision and is every bit as possible with non-discoverable credentials. As I see it, discoverable credentials enable a usernameless experience, which is a rather different phenomenon.

arianvanp 4y ago
You are correct.
- amluto 4y ago
  I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc? Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard.
  - dwaite 4y ago
    > I have to admit I don’t really see the point of making this be part of a secure token. The “username” store (actual username, tuple of (username, FIDO blob) or whatever) doesn’t seem terribly sensitive from a local attack perspective, but it is fairly sensitive from a privacy perspective. Wouldn’t it work better to have this be stored by a browser, per container, etc? An agent that registers non-discoverable credentials as discoverable ones via local storage is an option, although not one that browsers have yet chosen to support. This however locks you onto a browser (if it doesn't have a cloud sync fabric) or into a particular ecosystem (if that browser has a sync fabric). Authenticators support discoverability because a limitation of only being able to authenticate in a single browser is significant. Since authenticators tend to either support both discoverability and user verification, or neither discoverability nor user verification, I suspect there won't be business drivers to support such user agent storage/functionality. Note that the CredProtect extension protects discoverability of a resident credential without user verification, and Chrome requests this extension on sites' behalf by default. This protects against scenarios where a third party who gets physical access to your authenticator (thief, partner, law enforcement, border control) can introspect the websites you have accounts at without your participation. > Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard. There was a serious proposal: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension The challenge is that support for such things (new multisig algorithms, this recovery extension) require active relying party participation, and many would just choose not to take on the extra effort. So instead we have multi-device credentials, where there is a sync fabric behind the scenes. Nothing would preclude hardware credentials from participating in such a thing, although they would obviously need either radios or software assistance to do so. To capture the change in physical hardware, a new extension (devicePubKey) is being proposed under Web Authentication. This would have the benefit over the previous recoverability proposal in that sites opt-in to extra responsibility as needed for their business logic, compared to usability being restricted unless sites do extra work.

BoppreH 4y ago

I still see problems with recovery. You either have to (a) carry your primary and backup devices with you and risk losing both; (b) lower your security by using non-hardware-protected keys; or (c) be unable to create new accounts on-the-go. What I would like is a recovery key that I can store in a rarely-accessed safe. Here's an idea from an old paper of mine: on every sign up, you register not only your primary device, but also a recovery pair made of [hash(recovery_token), encrypt(master_public_key, recovery_token)]. Then you keep your single master_private_key in a safe. If you ever lose your primary device, you then: 1. Take your master_private_key from the safe (e.g., printed QR code, backup device, passphrase for key derivation, etc). 2. Ask the service for your encrypted recovery_token and decrypt it with your master_private_key. 3. Ask the service to reset your credentials and use the recovery_token as authentication, to be checked against the expected hash. This way you can create recoverable accounts without carrying your backup key, without downgrading to non-hardware security, without giving personal information like email address for out-of-band resets, and without creating a backup that has to be updated. As a bonus, you can use hash(master_public_key || service_domain) as username for anonymity without extra storage. And this process also works to recover compromised accounts, something you don't get with two Yubikeys that can remove each other.

sebk 4y ago
Your idea is not very different from this proposed spec also defined by Yubico: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys.
- BoppreH 4y ago
  > Your idea is not very different from this proposed spec also defined by Yubico: https://github.com/Yubico/webauthn-recovery-extension https://github.com/Yubico/webauthn-recovery-extension Good point, in that they are both based on backup credentials generated on-demand. But the Yubico scheme is a lot more complicated and limited to backup devices (as opposed to passphrase or printed QR code). On the other hand, the signed handover is really cool, and doesn't require the server to store encrypted data like in mine. > In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys. I agree completely.

crote 4y ago

I am very bearish about the current push to passkeys. To start with, why throw out the password? We have literally spend a decade getting people to use 2FA - and rightfully so. Why would we suddenly voluntarily compromise security and go back to 1FA? Sure, people suck at passwords, but even a poor password combined with an authenticator would be better than solely an authenticator. I am quite worried that websites will adopt this form of 1FA as the "new normal", compromising the security of anyone who still wishes to use secure passwords. Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature, but meanwhile vendors only allow syncing between their own devices. This makes a multi-vendor environment extremely challenging to use, not to mention that switching to another vendor risks losing access to a lot of websites. And that's even ignoring the possibility of a vendor getting mad at you and deciding to nuke your account - and all the passkeys with it. Until there is a proper (open!) standard for exporting and importing passkeys, this is an unacceptable risk to me. Some of this could be mitigated by a universal pluggable passkeys backend, but I am not really seeing any substantial movement in this direction. To me, it looks like Google/Apple are trying to replace "Log in with Google/Apple" with "Log in with Passkeys" to make it seem like it is an open platform, while still locking it down as tightly as possible. Despite being an open standard, the implementations are anything but. Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop. I am also seeing a lot of misleading statements surrounding its security. For example, the claims that the keys are stored in a TPM/Secure Enclave. Meanwhile, in practice the TPM is only used for the local encryption of a copy of your passkeys. They also happily live on the cloud because they are being synced, and the vendors seem to be offering ways to recover them without access to a single device. They seem to be intentionally reusing language traditionally reserved for security implementations where the private key is stored solely in a HSM with no way to export it, but that is not at all what is happening here. Security-wise, it's nothing more than a rebranded cloud-synced password vault. Meanwhile, hardware token vendors like Yubikey point this out, but they do not see it as a threat as they are selling this synced implementation as not suitable for high-security environments - and rightly so. Luckily, the protocol has a built-in way to bypass this: the passkey backend can be asked for attestation, which in essence is an immutable certificate embedded in the hardware key, signed by the hardware vendor. If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course. By hopping on the Passkeys bandwagon, they are able to erect significant barriers to entry for any potential competitors. Finally, Passkeys provide a privacy risk. With traditional Webauthn the user provides a username to the server, and the server responds with a set of opaque blobs which the user's tokens use for further bidirectional authorization. With Passkeys, the server asks the token for their set of domain-relevant passkeys, which include the username. This is required for the intended single-click usernameless login, but the flip side is that an attacker would be able to discover all of your accounts by probing the token. Alternatively, the server would be able to discover an association between multiple accounts of the same person, destroying attempts to retain an anonymous alt account. All in all, to me Passkeys looks like a thinly-veiled attempt to lock users into certain ecosystems, using convenience as a carrot-on-a-stick. Meanwhile, it adds significant security and privacy risks while claiming to be more secure. Seeing this being touted as a "more secure password replacement" by such major players makes me weep for the future.

simonjgreen 4y ago

What I see here is Yubico pushing for continued relevance while vendors, such as Microsoft and Apple, move to hybrid software hardware solutions with greater recoverability and without having to carry another piece of hardware with you. I applaud Yubico for what they've done over the years championing hardware multifactor, improved awareness of multifactor, and further in standards and acceptance. However, unless they pivot their model towards the OEM market and start selling there chips to phone manufacturers, I can't see them ever hitting the mainstream. Both Windows Hello and Microsoft Authenticator (in passwordless mode) are brilliant examples of passwordless done in a secure way that is also incredibly user friendly to both use and set up.

dwaite 4y ago
> What I see here is Yubico pushing for continued relevance while vendors, such as Microsoft and Apple, move to hybrid software hardware solutions with greater recoverability and without having to carry another piece of hardware with you. I applaud Yubico for what they've done over the years championing hardware multifactor, improved awareness of multifactor, and further in standards and acceptance. One important aspect is that Web Authentication is an abstraction API for talking to an authenticator. The authenticators themselves can have wildly different policy/characteristics. Apple in particular is pushing exclusively toward the consumer space requirements with their current implementation of Passkeys, solely as a more secure password replacement. This means that clone ability and sharability are fundamental concepts for them, which currently go against business and regulatory requirements in several spaces. Since mandating creation of hardware-bound credentials goes against consumer usability, there isn't a clear path toward supporting them outside enterprise enablement via MDM. Android's current plans are to only support hardware-bound credentials for second-factor usage, not for passwordless usage. Microsoft will likely allow for user choice as to whether a credential is hardware-bound. I'm not aware if they will allow the relying party to dictate a requirement here. Yubico meanwhile has a FIPS-certified key, and has been pushing toward support at higher assurance levels per NIST 800-63. While additional hardware is annoying for users, to the business it amounts to a per-seat cost to solve a real problem. > However, unless they pivot their model towards the OEM market and start selling there chips to phone manufacturers, I can't see them ever hitting the mainstream. They have an interesting model in that, while a business may need a user to have a Yubikey or similar authenticator, there often isn't a requirement that they have one specifically provisioned and shipped by the business. I've seen environments where key fobs are provisioned to users primarily through Amazon. So I suspect Yubikeys will settle into a business user and prosumer space, but no the chance of widespread consumer adoption was always slim. The broader adoption of WebAuthn gets however, the more opportunities I think Yubico will have to sell into the gaps. [Disclaimers: WebAuthn WG member, FIDO 2 TWG vice-chair]

butz 4y ago

Could anyone comment on recovery options? If Yubikey, smartphone or computer breaks, how do I login?

cuu508 4y ago
You use your second key.

cmdli 4y ago

To those who are interested in passkeys but are worried about vendor lock-in and lack of control, I would like to plug my solution, Bulwark Passkey (https://bulwark.id https://bulwark.id). It's an open source passkey manager that allows you to export your credentials outside the system, giving you more control. I think passkeys have a lot of potential to improve security and ease-of-use (passwords are broken!), but we need to maintain users' control over their data if that is going to happen.

fmajid 4y ago

If a passkey can be cloned via cloud authentication, it can also be cloned when a government compels the cloud service to "authenticate" your friendly neighborhood secret policeman as being you. That in itself is a good reason to only use uncloneable credentials like a Yubikey for sensitive uses.

TacticalCoder 4y ago
> That in itself is a good reason to only use uncloneable credentials like a Yubikey for sensitive uses. Yup I really don't get this. For once we had something that made sense: an actual 2FA which required an actual physical device. And now with the alliance between Microsoft (which we know can always be trusted), Google an Apple the 2FA not only is becoming "1FA" (because the goal is to use the passkey instead of the password, not in addition to it). But transforming the 2FA to 1FA is not enough: we cannot let these secure hardware module make live hard for law enforcement (uh, sorry, for bad guys) so instead of having "no device, no login" we get instead "copyable passkey". "1FA copyable passkey" What a concept. Somehow I feel this isn't exactly going forward security wise. Then people will say: "but it's easy. but it's convenient. And moreover it's pushed by our beloved Microsoft!". Yup, exactly.