10 ms·

Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probabl

Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. IMO physical security keys are better left as second-factor authentication, to be used _in addition_ to passkeys in certain high-security contexts; particularly where resistance to cloning is a critical feature. Resident keys aren't necessary for that use case since by the time you get to the second factor step you already know the account you're trying to log into. Further, the autocomplete functionality afforded by resident keys is important for the UX of passkeys in my opinion. I don't think it makes sense to sacrifice that in order to to retain backwards compatibility with a small number of keys that only security nerds use. (Though if there were a way to maintain that UX without using resident keys I'd be cool with that.)

the_snooze 3y ago
When I use a Yubikey for passwordless authentication (FIDO2), it challenges me for a PIN before asking me to touch the device. If I give it too many incorrect PINs, the Yubikey locks up and requires a device reset, which invalidates all previous registrations to use that key for authentication. It doesn't seem like a big deal if someone steals my hardware token. https://support.yubico.com/hc/en-us/articles/4402836718866-Understanding-YubiKey-PINs https://support.yubico.com/hc/en-us/articles/4402836718866-U...
- e40 3y ago
  That's not how my YK works. When I go to a new computer and login to my Google account, it asks me to insert it and press the button. Did I configure it wrong?
  - the_snooze 3y ago
    If you're only using it for two-factor authentication, you don't need a PIN. But when I tried to registered mine as a passkey (passwordless authentication), my browser prompted me for a PIN. I didn't have one set at the time, so it kept rejecting whatever PIN I gave it. I had to use the YubiKey Manager to set a PIN before I could register it as a a passkey. https://www.yubico.com/support/download/yubikey-manager/ https://www.yubico.com/support/download/yubikey-manager/
    - warp 3y ago
      You can also manage this from within Chrome (Privacy and security -> Security -> Manage security keys).
    - girvo 3y ago
      I use YubiCo Authenticator for TOTP via my YubiKey, and have a PIN setup due to that. Quite nice really, I imagine it's the same PIN you're talking about? I've not used it as a passkey yet
      - dwaite 3y ago
        Yubico sells Yubikeys where are smartcard devices loaded with several apps (keyboard emulation OTP, GPG, PIV card, and FIDO 2). They also sell cheaper security keys, which are purpose-built for FIDO 2 only. When someone says they are using a passkey with a Yubico device, they are talking specifically about the FIDO 2 functionality. This does not (at least currently) support import or export - partially because they want these devices to be sold in regulatory environments where hardware-bound and non-cloneable credentials are required.
  - jsmith99 3y ago
    It's optional and can be required by the service. Services like Microsoft that use security keys as a single factor rather than as a MFA are more likely to require it.
  - ilikepi 3y ago
    Are you sure you have a YubiKey (e.g. a "5 Series"[1]) and not a YubiCo "Security Key"[2]? The latter is a less expensive device with less functionality[3], though still good for arguably the most common 2FA situations. [1]: https://www.yubico.com/products/yubikey-5-overview/ https://www.yubico.com/products/yubikey-5-overview/ [2]: https://www.yubico.com/products/security-key/ https://www.yubico.com/products/security-key/ [3]: https://www.yubico.com/store/compare/ https://www.yubico.com/store/compare/
    - NoZebra120vClip 3y ago
      The Security Key models have an access PIN just the same.
  - hntway123 3y ago
    Something I noticed after reading this thread is that Google basically converted my YK from a 2FA security key to a Passkey. I'm so confused.
    - girvo 3y ago
      Now that is annoying, and I wish companies would not do that without asking.
  - yata69420 3y ago
    Yes, you need to use `ykman` to set a PIN. This also allows some services (really only Microsoft Accounts right now) to use "passwordless". The idea is you register 2 or 3 passwordless keys on important accounts. Keep one in the machine, one on your physical keychain, and one in a remote location.
- jauntywundrkind 3y ago
  It means though that your secure hardware token has a reliable way where the secrets all self-destruct. That someone can easily do if they get even brief hardware access. For people who have a problem keeping sufficient backups (almost everyone on earth) this seems like a horrific blocker, a show stopper for this entire intiative. I personally think these things absolutely should be able to be exported & backed up separately. Many people guffaw that now the device isn't secure. But I just don't think I could realistically adopt nor do I expect others will unless users get some better affordances, unless we get some capability to manage trust as we see fit, not just be pushed top down into someone else's desired much narrower security behavior. (Thankfully it seems like there is building interest in exports & portability, particularly as the OS/browser powered PassKeys arrives.)
  - JohnFen 3y ago
    > I personally think these things absolutely should be able to be exported & backed up separately. I agree. The usual response is that you don't need to do this because you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup. But managing that sounds like a real pain in the butt to me (honestly, the entire passkey system sounds like a real pain in the butt to me -- but that bit particularly so). But it looks like the major companies recognize that this is an issue and won't be requiring that part.
    - jauntywundrkind 3y ago
      It'd be awesome if you could ask to enroll a variety of other devices all at once, without having them on hand. Requiring ongoing physical access to your crucial backups to do any account enrollment or changes seems like a way to make sure you have your crucial backup way too close to potential disasters. Ideally I wanty backup keys many states away from me. But then I can enroll them! But it feels like there could be some kind of pubkey for those keys that I could also enroll at the same time as I'm getting my first device. Except these devices don't have just one pubkey cause that wouldn't be secure. Maybe they pre-make & share 20 keys with a peer device or something. Somehow though data needs to at the end be able to get into the backup/other device too though. Ugh it's wild.
politelemon 3y ago
I don't see phones as being very different in terms of also being a physical security key.
- prophesi 3y ago
  I think the key (pun not intended) differences are that phones are something you'll always have on your person, Apple/Google will allow it to sync across devices, and phones require a pin/biometrics to authenticate with them.
  - caminante 3y ago
    Have you not heard of "SIM swapping?" [0] The FBI (US) receives thousands of complaints, which I'm guessing means it's orders of magnitude more common. [0]https://blog.mozilla.org/en/privacy-security/mozilla-explains-sim-swapping/ https://blog.mozilla.org/en/privacy-security/mozilla-explain...
    - giobox 3y ago
      Using phones as physical security keys != using SMS for 2FA.
    - naikrovek 3y ago
      sim swapping doesn't move the authenticator app to the attackers phone, only your phone number. this is why SMS-based 2nd factor has been considered insecure for years.
    - jrk 3y ago
      SIM swapping lets you take over a phone number. It does not let you clone the keys stored in your physical phone’s secure storage / enclave / key storage. So SIM swapping makes SMS verification vulnerable (that just depends on controlling the phone number), but doesn’t fundamentally affect iPhone/Android passkeys.
    - zb3 3y ago
      There are two separate problems - the first one is to make sure others don't have the access you don't want them to, while the other is to make sure that you/others have the authorized access. SIM swapping means someone else might be able to have my phone number, but I'll eventually get this number back via legal means. So the number itself is something I own (at least in my country). Now if a site assumed this and phone numbers were meant to be constant, it'd mean I could always get my account back. But of course this depends on which problem I consider more important. It's better to lose access to my FB account forever than to allow someone to gain access to it for a moment, because that might cause harm. Similarily, it's better to lose access to my bank account until I have to visit them in person than to lose all the money, but in this case the weakest link is probably not the key itself.
aseipp 3y ago
Yeah, this is basically my take. At this point, the idea everyone is converged on is that you have a locally encrypted secure "vault" of some kind, that you can trust, and you need to verify identity with that system, perhaps with a password and perhaps with a key. It is easier to have some trust that your password manager of choice is more secure, rather than having to assume that every service in existence you create an account for is secure (or unphishable.) So, by the time you use a passkey, you're quite often in a more secure context where you've already established that identity: to your operating system, to your password manager that owns your passkeys, etc. It also seems likely that places that didn't support hardware keys now or recently probably wouldn't have supported them in the near future. But the ROI for a Passkey solution is likely much higher since the buy in (just some software support) is much easier for people to achieve. Of course, this is only true for websites mainly; a Passkey is basically the equivalent of "Standardized SSH keys" for a website. I see hardware keys as more useful for second factors like actually unlocking your vault with your passkeys inside of it, which might also want a password. I suspect hardware keys still have a bit of life left in them. The Passkey login flow is actually super, super nice now that I can use it on GitHub, Gmail, etc as a primary method.
katbyte 3y ago
i think they could be great for websites i don't really care about and already use weaker passwords. but for important sites where security matters? nope
- aseipp 3y ago
  Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. For "important sites where security matters" they are literally better in every way than a password, it doesn't matter how weak or strong. You can use a pure software solution, and soon probably even your existing password manager, to handle them. Again, you should think of them as replacing passwords. You can still enforce post-authentication requirements like SMS or calls to known numbers, bank account deposits, magic follow-up links in a confirmed email, push notifications, etc. SSH keys are the best analogy. "SSH keys are great for useless servers, but for important servers? no way!" No! That's exactly where SSH keys are most useful. And you also happen to encrypt your SSH keys locally with a password, don't you? This is the exact same principle, but applied to arbitrary websites. Nobody goes around randomly generating login passwords for SSH'ing into each and every server they use, and then pats themselves on the back.
  - Eduard 3y ago
    > Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. Let's assume a "passkey device emulator" written in software; quite realistic IMHO for someone to use, considering the cost of hardware authentication devices (phones, YubiKey etc.) If someone using such emulator gets hacked and has their passkey emulator data stolen, is there anything preventing a credential leak?
    - aseipp 3y ago
      The software you're describing is called a "Password Manager", and several do support passkeys already in newer versions. There's no real "emulation." 1Password 8 supports them just fine, your browser has APIs so third-party software can integrate exactly for that. So, the answer to your question is pretty much "exactly the same scenario as your password manager getting leaked", which is basically unsurprising and already well understood when you frame it this way, I think. The particular case I was referring to (and probably should have been clearer about) was when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use. But like, that's actually a major issue in practice, because the value of hacking a service operator is often far greater than just one user. That exact scenario was one of the motivations for using password managers in the first place, too, to mitigate operators getting hacked and common passwords getting reused between users, thus turning a single compromise for many users into multiple compromises for many users. So, it all has come full circle in a sense; now we've finally recognized that instead than shoehorning passwords into becoming psuedo-random strings that might as well be base64 encoded bytes from /dev/urandom, you might as well go "all the way" and just get those raw bytes from /dev/urandom directly and then use them as key material for a public key exchange. Again, the best analogy is to just imagine that you used SSH keys to log into a website. That's all this is. It's software. Then you remember: oh yeah, SSH key synchronization and enrollment across machines sucks ass, and normal people would hate doing it. Hey, you know what, we already use passwords to encrypt SSH keys -- so what if we added a storage synchronization layer between your machines to keep those SSH private keys synchronized, encrypted with that password, and stored using $FAVORITE_SERVICE_PROVIDER? That's pretty much it, in a nutshell. You just reinvented modern Passkeys. Most of the threat models at that point are well understood: what service provider or software to choose, how secure is the local encryption, should you use two-factor authentication to further improve unlock safety, etc.
mrtksn 3y ago
If you think about it, the core problem can be described as "authentication of the biological being with an electronic system". When passwords are used, the authentication interface is a keyboard and you don't have any actual guarantees that the person typing the password is the person who claims to be. The passwords could have been extracted in so many ways because it depends on easily transferable knowledge. Moving the authentication interface to device2device is actually much better, you no longer assume that the easily transferable knowledge was not transferred. Instead, you assume that the biological being is capable of keeping track of the authentication device and people are naturally good at it. You can increase the number of authentication channels to tighten it up a bit, you can restrict the authentication of the biological being with the device(FaceID) which will be used for authentication with remote systems but at the core I think it feels right to assume device(phone, key etc.) means the person. It's also quite a human thing to do. At home, we share not only the Netflix password but one of the credit cards. For practical reason, one credit card stays with the spare keys and when there's something to buy for the house anyone can grab that card and use it. We trust each other that the card would be used properly, everyone knows the pin code but that's rarely needed since contactless payment is the norm anyway. It's much more natural than keeping track of the expenses and then pay each other the outstanding amounts. However, It's probably illegal and if the bank finds out about it, they will cancel the card. IMHO, the IT systems desperately need to approach human behaviour by working in analogous ways with the real world. Since I'm involved with IT systems I don't struggle most of the time but people who are not that tech savvy are having hard time figuring out daily stuff like What is the iPhone's password for, What is the iCloud password for, what is the Gmail password for, why I need to enter a code in WhatsApp etc. Actually, I think I struggle too - I never came along to understand Mastadon. I'm prbably defenceless against phishing attacks on Mastadon, I will type whatever the screen tells me to type.
- JohnFen 3y ago
  > it's probably illegal and if the bank finds out about it, they will cancel the card. In the US, anyway, this isn't illegal unless you have to sign something and sign someone else's name. So just sign your own (nobody actually checks signatures). It might be against the CC issuer's terms of service, of course, but that's a whole lot different from being illegal.
newhouseb 3y ago
I've been trying to wrap my head around this and my layman understanding is that there's an assumption (but maybe not baked into any requirements/standard) that use of the hardware key is locked behind either a biometric check (FaceID/TouchID/etc) or password. In other words, there might be an implicit second factor baked in to the passkey itself.
- dwaite 3y ago
  A passkey is a discoverable credential (meaning - a website can ask the system for it without knowing who the user is first) with user verification (meaning, it can ask the system providing the passkey to verify the user). For a platform like a mobile phone or laptop, this user verification might be a biometric or a system password/pin confirmation. For a security key fob, they may have a fingerprint reader or a pin entry pad. Or, they may ask the browser/phone/laptop to prompt for PIN entry on their behalf. One could imagine a wearable using a biometric scan, or even monitoring for continuous wear and only asking for a confirmation gesture/tap. WebAuthn is an API to talk to authenticators, and authenticators are a box which could hold anything from a single factor to a full authentication process.
jrockway 3y ago
I'm not sure that a second factor was ever the goal of 2FA, but rather the desire was a key that users couldn't pick themselves (because they use their birthday, they tell example.com their Google password every time they log in, etc.) That said, I don't feel great about letting security keys be the only factor. They can be stolen. So can phones, but phones make you unlock them before they'll be your password. (Windows Hello is the same thing.) That seems like the right balance to me. Your phone can authenticate that you are you; a USB dongle can't.
- dwaite 3y ago
  Modern security keys (made in the last 5 years or so) support CTAP 2, which will support setting and using a PIN even if there is no hardware keypad. The client system will prompt for the PIN before letting you use the credential. Chrome I believe will walk you through setting up a PIN the first time if a site requests user verification, while last I checked Apple platforms require it to already be configured.
drdaeman 3y ago
Until there is something like pre-registration ("here are all my keys from all my devices, trust them all" - not possible with current standards) mechanism - I suppose, yes? I don't really understand if there's any other way to make all this work if not for portable authenticators. How one is supposed to log in from a different machine if it's from a different ecosystem that doesn't have the original passkey (e.g. log in on an iPhone if I've signed up from a non-Apple desktop computer)?
- dwaite 3y ago
  For the other direction (phone providing computer access), there is a hybrid flow. You select an option like 'use passkey from another device', and it will pop up a QR code. Scan that with your phone/tablet, and it will provide the interface to confirm and authenticate on your phone. That then lets your computer in. Some sites may have flows to detect you used a credential from another device when your local device supports passkeys, and just prompt you if you want to register a second passkey to make things easier in the future. There's nothing that prevents a computer from scanning a phone-displayed QR code to work in your given direction, except that it is not what a user would expect. Dashlane and 1Password have support for providing passkeys via browser extensions, which provide different sync 'boundaries'. Android and Apple OS's both have beta API to provide these apps the ability to plug in at a system level. It's feasible that even Apple/Google could publish apps that use these API on one another's platforms.
  - drdaeman 3y ago
    > You select an option like 'use passkey from another device' Is this a part of any standard? It most certainly not a part of any Webauthn spec, and sites I've seen that mentioned Passkeys did not offer this option.
    - dwaite 3y ago
      This is implemented in various platforms/browsers, deployed over the last 10 or so months. I believe Microsoft may have added this in the latest Win11 previews. I'll point to this somewhat random article for the pictures of it working on an Apple laptop (under 'Other options' in this case). https://www.pcmag.com/news/with-some-help-apple-passkeys-could-finally-kill-the-password https://www.pcmag.com/news/with-some-help-apple-passkeys-cou...
jrozner 3y ago
When using a resident/discoverable credential the authenticator is supposed to authenticate the user (using a pin, biometrics, etc.) This fulfills the multi-factor requirement. All passkeys/webauthn credentials are something you have and you can use a something to know/something to are to unlock the credential stored on the authenticator.
- dwaite 3y ago
  Platform authenticators have made it more obvious that some people took the multi-factor model as some immutable truth of the universe. The modeling of authentication techniques as factors shows the strengths and weaknesses of the categories. The purpose of 2FA was to pitch instead to use authentication processes that counteract the weaknesses through layering. Platform authenticators aren't just providing an authentication technique - they are a user-supplied authentication and recovery process. Even understanding the entire workflow of that process, you may not have the ability to retrofit that into a _larger_ process to meet your regulatory and security requirements. But that workflow is actually per vendor, per device, configurable by the end user, and evolving over time. This has been an ongoing problem for ages, because the 'knowledge factor' was actually often something the user didn't know, but something provided by a software agent (password manager) which had its own configurable authentication and recovery processes. It just eventually got ignored as people shifted to thinking of the second factor as 'the thing that makes up for all possible weaknesses of the password'. IMHO this is why passkeys are pitched as a replacement for passwords, e.g. as a knowledge factor. It may eliminate your site's need for another factor if you were mostly concerned about phishing. It stops you from needing to use breach lists, and limits the impact if your credential table gets exposed. It isn't a great fit for regulated/secure environments, which may still need to do all the same additional factors for risk mitigation or compliance. This is a very complex problem to solve, though - platforms are not going to want to act against their users' expectations, such as losing all banking credentials when you get a new phone.
wkat4242 3y ago
> Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them Yes because the keys have a PIN just for this usecase. Similar to the ATM card or SIM card you already know
- cycomanic 3y ago
  The impression that I get though is that the PIN's are typically short (especially if we have to enter them every time it is to access the key). Now, how physically save are hardware keys that the actual private key can't be extracted from them? In contrast to an ATM or SIM we essentially rely on the device to enforce the "max number of attempts", not an external entity. Once the key is extracted brute forcing the PIN is not a problem, because it likely is going to be simple. Unless somehow the devices are going to enforce long PINs.
  - wkat4242 3y ago
    The PIN doesn't have to be long because the key will block itself after a very limited number of attempts. Just like with your bank card. Extracting the key is another issue but the chips used in these are hardened. They are just like the secure element in phones.
throwaway892238 3y ago
Password managers have already made passwords obsolete. I literally don't know any of my passwords except my master one. Passkeys are an insanely overcomplicated solution we don't really need. Browsers just need a simple HATEOAS API for password managers to hook into, and web apps expose some HTML that triggers the browser. The password manager can then determine how to authenticate the user (however the user wants!), auto-inject the secret for that website, and the user is automatically logged in. E-mail reset if anything goes wrong. From the "we're a website that wants super fancy security" perspective, I get that they want something more complex. But there should be levels of security that the user can opt-in to. For example: most websites are fine with a simple password hash, assuming the password manager uses random passwords. Any website can implement that, every password manager can implement that, and it's better than 99% of regular users' password use today. So there's your baseline auth method. Then if you want something like TOTP, OIDC, public-key crypto, etc the server can advertise it, the client can opt-in to it, and authentication can continue. But not every site needs to implement it, and not every user cares to use it. Basically, we don't need every site and every user to use the most secure methods. We just need to make it easier to get a baseline of improved security, and allow people to slowly opt-in to stronger security.
- XorNot 3y ago
  Frankly I don't like the website getting to determine how I practice my own personal security: that's just the path of corporate lock-in, and it also has exactly one outcome - everyone will select either "maximum" because "that's secure" or "minimum" because "user experience". It's the worst of both worlds (i.e. the insufferable thing banks do where they try to force you to type in your password with the mouse).
- dcow 3y ago
  > Passkeys are an insanely overcomplicated solution we don't really need. This is simply not true. WebAuthN is not overcomplicated needlessly (I wouldn't even call it overcomplicated, it's literally just a signed challenge/response dance). It improves on Passwords+2FA in a few notable ways: 1. It prevents shared secrets from traversing the wire. 2. It naturally enforces that users are all using secure authentication keys without password rules nonsense. 3. It kills 2FA by allowing Relying Parties to request user presence verification as part of the primary challenge. 4. It is origin-bound which mitigates phishing. Passwords don't have any of these properties. And since your password manager handles the details for you, why wouldn't you want it to improve its implementation under the hood making things better for you with zero effort on your part?
amadeuspagel 3y ago
Physical security keys can have pins.
0x4e53 3y ago
Realistically, I don't think this will completely replace Yubikeys, nor do I think that only "security nerds" use them. In reality - the majority of leading organizations use Yubikeys to secure authentication across their company. While it's likely not as common for consumers, it is probably the most trusted solution in the enterprise today.
- androidbishop 3y ago
  you can use yubikey 5s as passkeys
ivlad 3y ago
> Passkeys are meant to be a password _replacement_, No. Passkeys parasitize on FIDO2 U2F standard, that was developed to be (as the name implies) the second factor. Resident keys are meant for on-device 2FA with PIN, a functional replacement of smart cards. Someone (Apple maybe) thought it’s a good idea to consider WebAuthn being good enough to be the only authentication factor (no resident keys, no hardware bond, keys are roamed via iCloud) but TouchID/FaceID protected on device. And they branded them as passkeys. > and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. You don’t. 2FA is not a goal on itself. The goal is to have user authentication that is protected from phishing, brute force and credential stuffing, and also not as hard to implement as smart cards. FIDO2 does that. The problem with Apple’s, Google’s or Microsoft’s implementations is not that they are less secure on a protocol level between the authenticating site and the user’s device, that’s exactly the same protocol. The problem is that the site has now to trust user’s personal account in one of these platforms and that the user did the right thing and also the platforms will always be doing the right thing - e.g., they will handle attacks on user’s personal account properly.
- dwaite 3y ago
  > Passkeys parasitize on FIDO2 U2F standard U2F authenticators and the U2F protocol cannot support passkeys. A passkey is a discoverable credential which supports user verification. U2F supports neither discoverability nor user verification. Passkeys as a user-facing term is meant to describe a user experience. Second factor authentication using U2F is a different experience. > The problem is that the site has now to trust user’s personal account in one of these platforms and that the user did the right thing and also the platforms will always be doing the right thing - e.g., they will handle attacks on user’s personal account properly. That is in fact how passwords work today. You can't tell if my password came from my head or from a excel spreadsheet printout I carry around in my wallet; from a cloud synchronized password manager or if I use the same password for every website which will accept it (otherwise, I will add exclamation marks to the end until it does).
- NoZebra120vClip 3y ago
vaxman 3y ago
Passkeys combat phishing and sell mobile devices that have secure enclaves, tho the mobile operating software is apparently syncing the master key between devices enrolled in the same subscriber account. However, during MOST urban assaults, phone theft/damage is among the first thing to happen. It’s why all of this phone-as-token crud combined with FaceID are bad ideas that put convenience above security. The government should be pushing everyone into a federal SSO so that this is not needed and so they don’t need to worry so much about encryption.
heavyset_go 3y ago
> Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. Hardware security keys that implement FIDO2 UAF can be protected by PINs/passwords or biometrics, the former being "something you know", and the latter "something you are", with the security key itself being "something you have".
thayne 3y ago
Which is why the author mentioned using a pin or biometrics to unlock the hardware security device.

the_snooze 3y ago

When I use a Yubikey for passwordless authentication (FIDO2), it challenges me for a PIN before asking me to touch the device. If I give it too many incorrect PINs, the Yubikey locks up and requires a device reset, which invalidates all previous registrations to use that key for authentication. It doesn't seem like a big deal if someone steals my hardware token. https://support.yubico.com/hc/en-us/articles/4402836718866-Understanding-YubiKey-PINs https://support.yubico.com/hc/en-us/articles/4402836718866-U...

e40 3y ago
That's not how my YK works. When I go to a new computer and login to my Google account, it asks me to insert it and press the button. Did I configure it wrong?
- the_snooze 3y ago
  If you're only using it for two-factor authentication, you don't need a PIN. But when I tried to registered mine as a passkey (passwordless authentication), my browser prompted me for a PIN. I didn't have one set at the time, so it kept rejecting whatever PIN I gave it. I had to use the YubiKey Manager to set a PIN before I could register it as a a passkey. https://www.yubico.com/support/download/yubikey-manager/ https://www.yubico.com/support/download/yubikey-manager/
  - warp 3y ago
    You can also manage this from within Chrome (Privacy and security -> Security -> Manage security keys).
  - girvo 3y ago
    I use YubiCo Authenticator for TOTP via my YubiKey, and have a PIN setup due to that. Quite nice really, I imagine it's the same PIN you're talking about? I've not used it as a passkey yet
    - dwaite 3y ago
      Yubico sells Yubikeys where are smartcard devices loaded with several apps (keyboard emulation OTP, GPG, PIV card, and FIDO 2). They also sell cheaper security keys, which are purpose-built for FIDO 2 only. When someone says they are using a passkey with a Yubico device, they are talking specifically about the FIDO 2 functionality. This does not (at least currently) support import or export - partially because they want these devices to be sold in regulatory environments where hardware-bound and non-cloneable credentials are required.
- jsmith99 3y ago
  It's optional and can be required by the service. Services like Microsoft that use security keys as a single factor rather than as a MFA are more likely to require it.
- ilikepi 3y ago
  Are you sure you have a YubiKey (e.g. a "5 Series"[1]) and not a YubiCo "Security Key"[2]? The latter is a less expensive device with less functionality[3], though still good for arguably the most common 2FA situations. [1]: https://www.yubico.com/products/yubikey-5-overview/ https://www.yubico.com/products/yubikey-5-overview/ [2]: https://www.yubico.com/products/security-key/ https://www.yubico.com/products/security-key/ [3]: https://www.yubico.com/store/compare/ https://www.yubico.com/store/compare/
  - NoZebra120vClip 3y ago
    The Security Key models have an access PIN just the same.
- hntway123 3y ago
  Something I noticed after reading this thread is that Google basically converted my YK from a 2FA security key to a Passkey. I'm so confused.
  - girvo 3y ago
    Now that is annoying, and I wish companies would not do that without asking.
- yata69420 3y ago
  Yes, you need to use `ykman` to set a PIN. This also allows some services (really only Microsoft Accounts right now) to use "passwordless". The idea is you register 2 or 3 passwordless keys on important accounts. Keep one in the machine, one on your physical keychain, and one in a remote location.
jauntywundrkind 3y ago
It means though that your secure hardware token has a reliable way where the secrets all self-destruct. That someone can easily do if they get even brief hardware access. For people who have a problem keeping sufficient backups (almost everyone on earth) this seems like a horrific blocker, a show stopper for this entire intiative. I personally think these things absolutely should be able to be exported & backed up separately. Many people guffaw that now the device isn't secure. But I just don't think I could realistically adopt nor do I expect others will unless users get some better affordances, unless we get some capability to manage trust as we see fit, not just be pushed top down into someone else's desired much narrower security behavior. (Thankfully it seems like there is building interest in exports & portability, particularly as the OS/browser powered PassKeys arrives.)
- JohnFen 3y ago
  > I personally think these things absolutely should be able to be exported & backed up separately. I agree. The usual response is that you don't need to do this because you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup. But managing that sounds like a real pain in the butt to me (honestly, the entire passkey system sounds like a real pain in the butt to me -- but that bit particularly so). But it looks like the major companies recognize that this is an issue and won't be requiring that part.
  - jauntywundrkind 3y ago
    It'd be awesome if you could ask to enroll a variety of other devices all at once, without having them on hand. Requiring ongoing physical access to your crucial backups to do any account enrollment or changes seems like a way to make sure you have your crucial backup way too close to potential disasters. Ideally I wanty backup keys many states away from me. But then I can enroll them! But it feels like there could be some kind of pubkey for those keys that I could also enroll at the same time as I'm getting my first device. Except these devices don't have just one pubkey cause that wouldn't be secure. Maybe they pre-make & share 20 keys with a peer device or something. Somehow though data needs to at the end be able to get into the backup/other device too though. Ugh it's wild.

politelemon 3y ago

I don't see phones as being very different in terms of also being a physical security key.

prophesi 3y ago
I think the key (pun not intended) differences are that phones are something you'll always have on your person, Apple/Google will allow it to sync across devices, and phones require a pin/biometrics to authenticate with them.
- caminante 3y ago
  Have you not heard of "SIM swapping?" [0] The FBI (US) receives thousands of complaints, which I'm guessing means it's orders of magnitude more common. [0]https://blog.mozilla.org/en/privacy-security/mozilla-explains-sim-swapping/ https://blog.mozilla.org/en/privacy-security/mozilla-explain...
  - giobox 3y ago
    Using phones as physical security keys != using SMS for 2FA.
  - naikrovek 3y ago
    sim swapping doesn't move the authenticator app to the attackers phone, only your phone number. this is why SMS-based 2nd factor has been considered insecure for years.
  - jrk 3y ago
    SIM swapping lets you take over a phone number. It does not let you clone the keys stored in your physical phone’s secure storage / enclave / key storage. So SIM swapping makes SMS verification vulnerable (that just depends on controlling the phone number), but doesn’t fundamentally affect iPhone/Android passkeys.
  - zb3 3y ago
    There are two separate problems - the first one is to make sure others don't have the access you don't want them to, while the other is to make sure that you/others have the authorized access. SIM swapping means someone else might be able to have my phone number, but I'll eventually get this number back via legal means. So the number itself is something I own (at least in my country). Now if a site assumed this and phone numbers were meant to be constant, it'd mean I could always get my account back. But of course this depends on which problem I consider more important. It's better to lose access to my FB account forever than to allow someone to gain access to it for a moment, because that might cause harm. Similarily, it's better to lose access to my bank account until I have to visit them in person than to lose all the money, but in this case the weakest link is probably not the key itself.

aseipp 3y ago

Yeah, this is basically my take. At this point, the idea everyone is converged on is that you have a locally encrypted secure "vault" of some kind, that you can trust, and you need to verify identity with that system, perhaps with a password and perhaps with a key. It is easier to have some trust that your password manager of choice is more secure, rather than having to assume that every service in existence you create an account for is secure (or unphishable.) So, by the time you use a passkey, you're quite often in a more secure context where you've already established that identity: to your operating system, to your password manager that owns your passkeys, etc. It also seems likely that places that didn't support hardware keys now or recently probably wouldn't have supported them in the near future. But the ROI for a Passkey solution is likely much higher since the buy in (just some software support) is much easier for people to achieve. Of course, this is only true for websites mainly; a Passkey is basically the equivalent of "Standardized SSH keys" for a website. I see hardware keys as more useful for second factors like actually unlocking your vault with your passkeys inside of it, which might also want a password. I suspect hardware keys still have a bit of life left in them. The Passkey login flow is actually super, super nice now that I can use it on GitHub, Gmail, etc as a primary method.

katbyte 3y ago

i think they could be great for websites i don't really care about and already use weaker passwords. but for important sites where security matters? nope

aseipp 3y ago
Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. For "important sites where security matters" they are literally better in every way than a password, it doesn't matter how weak or strong. You can use a pure software solution, and soon probably even your existing password manager, to handle them. Again, you should think of them as replacing passwords. You can still enforce post-authentication requirements like SMS or calls to known numbers, bank account deposits, magic follow-up links in a confirmed email, push notifications, etc. SSH keys are the best analogy. "SSH keys are great for useless servers, but for important servers? no way!" No! That's exactly where SSH keys are most useful. And you also happen to encrypt your SSH keys locally with a password, don't you? This is the exact same principle, but applied to arbitrary websites. Nobody goes around randomly generating login passwords for SSH'ing into each and every server they use, and then pats themselves on the back.
- Eduard 3y ago
  > Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. Let's assume a "passkey device emulator" written in software; quite realistic IMHO for someone to use, considering the cost of hardware authentication devices (phones, YubiKey etc.) If someone using such emulator gets hacked and has their passkey emulator data stolen, is there anything preventing a credential leak?
  - aseipp 3y ago
    The software you're describing is called a "Password Manager", and several do support passkeys already in newer versions. There's no real "emulation." 1Password 8 supports them just fine, your browser has APIs so third-party software can integrate exactly for that. So, the answer to your question is pretty much "exactly the same scenario as your password manager getting leaked", which is basically unsurprising and already well understood when you frame it this way, I think. The particular case I was referring to (and probably should have been clearer about) was when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use. But like, that's actually a major issue in practice, because the value of hacking a service operator is often far greater than just one user. That exact scenario was one of the motivations for using password managers in the first place, too, to mitigate operators getting hacked and common passwords getting reused between users, thus turning a single compromise for many users into multiple compromises for many users. So, it all has come full circle in a sense; now we've finally recognized that instead than shoehorning passwords into becoming psuedo-random strings that might as well be base64 encoded bytes from /dev/urandom, you might as well go "all the way" and just get those raw bytes from /dev/urandom directly and then use them as key material for a public key exchange. Again, the best analogy is to just imagine that you used SSH keys to log into a website. That's all this is. It's software. Then you remember: oh yeah, SSH key synchronization and enrollment across machines sucks ass, and normal people would hate doing it. Hey, you know what, we already use passwords to encrypt SSH keys -- so what if we added a storage synchronization layer between your machines to keep those SSH private keys synchronized, encrypted with that password, and stored using $FAVORITE_SERVICE_PROVIDER? That's pretty much it, in a nutshell. You just reinvented modern Passkeys. Most of the threat models at that point are well understood: what service provider or software to choose, how secure is the local encryption, should you use two-factor authentication to further improve unlock safety, etc.

mrtksn 3y ago

If you think about it, the core problem can be described as "authentication of the biological being with an electronic system". When passwords are used, the authentication interface is a keyboard and you don't have any actual guarantees that the person typing the password is the person who claims to be. The passwords could have been extracted in so many ways because it depends on easily transferable knowledge. Moving the authentication interface to device2device is actually much better, you no longer assume that the easily transferable knowledge was not transferred. Instead, you assume that the biological being is capable of keeping track of the authentication device and people are naturally good at it. You can increase the number of authentication channels to tighten it up a bit, you can restrict the authentication of the biological being with the device(FaceID) which will be used for authentication with remote systems but at the core I think it feels right to assume device(phone, key etc.) means the person. It's also quite a human thing to do. At home, we share not only the Netflix password but one of the credit cards. For practical reason, one credit card stays with the spare keys and when there's something to buy for the house anyone can grab that card and use it. We trust each other that the card would be used properly, everyone knows the pin code but that's rarely needed since contactless payment is the norm anyway. It's much more natural than keeping track of the expenses and then pay each other the outstanding amounts. However, It's probably illegal and if the bank finds out about it, they will cancel the card. IMHO, the IT systems desperately need to approach human behaviour by working in analogous ways with the real world. Since I'm involved with IT systems I don't struggle most of the time but people who are not that tech savvy are having hard time figuring out daily stuff like What is the iPhone's password for, What is the iCloud password for, what is the Gmail password for, why I need to enter a code in WhatsApp etc. Actually, I think I struggle too - I never came along to understand Mastadon. I'm prbably defenceless against phishing attacks on Mastadon, I will type whatever the screen tells me to type.

JohnFen 3y ago
> it's probably illegal and if the bank finds out about it, they will cancel the card. In the US, anyway, this isn't illegal unless you have to sign something and sign someone else's name. So just sign your own (nobody actually checks signatures). It might be against the CC issuer's terms of service, of course, but that's a whole lot different from being illegal.

newhouseb 3y ago

I've been trying to wrap my head around this and my layman understanding is that there's an assumption (but maybe not baked into any requirements/standard) that use of the hardware key is locked behind either a biometric check (FaceID/TouchID/etc) or password. In other words, there might be an implicit second factor baked in to the passkey itself.

dwaite 3y ago
A passkey is a discoverable credential (meaning - a website can ask the system for it without knowing who the user is first) with user verification (meaning, it can ask the system providing the passkey to verify the user). For a platform like a mobile phone or laptop, this user verification might be a biometric or a system password/pin confirmation. For a security key fob, they may have a fingerprint reader or a pin entry pad. Or, they may ask the browser/phone/laptop to prompt for PIN entry on their behalf. One could imagine a wearable using a biometric scan, or even monitoring for continuous wear and only asking for a confirmation gesture/tap. WebAuthn is an API to talk to authenticators, and authenticators are a box which could hold anything from a single factor to a full authentication process.

jrockway 3y ago

I'm not sure that a second factor was ever the goal of 2FA, but rather the desire was a key that users couldn't pick themselves (because they use their birthday, they tell example.com their Google password every time they log in, etc.) That said, I don't feel great about letting security keys be the only factor. They can be stolen. So can phones, but phones make you unlock them before they'll be your password. (Windows Hello is the same thing.) That seems like the right balance to me. Your phone can authenticate that you are you; a USB dongle can't.

dwaite 3y ago
Modern security keys (made in the last 5 years or so) support CTAP 2, which will support setting and using a PIN even if there is no hardware keypad. The client system will prompt for the PIN before letting you use the credential. Chrome I believe will walk you through setting up a PIN the first time if a site requests user verification, while last I checked Apple platforms require it to already be configured.

drdaeman 3y ago

Until there is something like pre-registration ("here are all my keys from all my devices, trust them all" - not possible with current standards) mechanism - I suppose, yes? I don't really understand if there's any other way to make all this work if not for portable authenticators. How one is supposed to log in from a different machine if it's from a different ecosystem that doesn't have the original passkey (e.g. log in on an iPhone if I've signed up from a non-Apple desktop computer)?

dwaite 3y ago
For the other direction (phone providing computer access), there is a hybrid flow. You select an option like 'use passkey from another device', and it will pop up a QR code. Scan that with your phone/tablet, and it will provide the interface to confirm and authenticate on your phone. That then lets your computer in. Some sites may have flows to detect you used a credential from another device when your local device supports passkeys, and just prompt you if you want to register a second passkey to make things easier in the future. There's nothing that prevents a computer from scanning a phone-displayed QR code to work in your given direction, except that it is not what a user would expect. Dashlane and 1Password have support for providing passkeys via browser extensions, which provide different sync 'boundaries'. Android and Apple OS's both have beta API to provide these apps the ability to plug in at a system level. It's feasible that even Apple/Google could publish apps that use these API on one another's platforms.
- drdaeman 3y ago
  > You select an option like 'use passkey from another device' Is this a part of any standard? It most certainly not a part of any Webauthn spec, and sites I've seen that mentioned Passkeys did not offer this option.
  - dwaite 3y ago
    This is implemented in various platforms/browsers, deployed over the last 10 or so months. I believe Microsoft may have added this in the latest Win11 previews. I'll point to this somewhat random article for the pictures of it working on an Apple laptop (under 'Other options' in this case). https://www.pcmag.com/news/with-some-help-apple-passkeys-could-finally-kill-the-password https://www.pcmag.com/news/with-some-help-apple-passkeys-cou...

jrozner 3y ago

When using a resident/discoverable credential the authenticator is supposed to authenticate the user (using a pin, biometrics, etc.) This fulfills the multi-factor requirement. All passkeys/webauthn credentials are something you have and you can use a something to know/something to are to unlock the credential stored on the authenticator.

dwaite 3y ago
Platform authenticators have made it more obvious that some people took the multi-factor model as some immutable truth of the universe. The modeling of authentication techniques as factors shows the strengths and weaknesses of the categories. The purpose of 2FA was to pitch instead to use authentication processes that counteract the weaknesses through layering. Platform authenticators aren't just providing an authentication technique - they are a user-supplied authentication and recovery process. Even understanding the entire workflow of that process, you may not have the ability to retrofit that into a _larger_ process to meet your regulatory and security requirements. But that workflow is actually per vendor, per device, configurable by the end user, and evolving over time. This has been an ongoing problem for ages, because the 'knowledge factor' was actually often something the user didn't know, but something provided by a software agent (password manager) which had its own configurable authentication and recovery processes. It just eventually got ignored as people shifted to thinking of the second factor as 'the thing that makes up for all possible weaknesses of the password'. IMHO this is why passkeys are pitched as a replacement for passwords, e.g. as a knowledge factor. It may eliminate your site's need for another factor if you were mostly concerned about phishing. It stops you from needing to use breach lists, and limits the impact if your credential table gets exposed. It isn't a great fit for regulated/secure environments, which may still need to do all the same additional factors for risk mitigation or compliance. This is a very complex problem to solve, though - platforms are not going to want to act against their users' expectations, such as losing all banking credentials when you get a new phone.

wkat4242 3y ago

> Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them Yes because the keys have a PIN just for this usecase. Similar to the ATM card or SIM card you already know

cycomanic 3y ago
The impression that I get though is that the PIN's are typically short (especially if we have to enter them every time it is to access the key). Now, how physically save are hardware keys that the actual private key can't be extracted from them? In contrast to an ATM or SIM we essentially rely on the device to enforce the "max number of attempts", not an external entity. Once the key is extracted brute forcing the PIN is not a problem, because it likely is going to be simple. Unless somehow the devices are going to enforce long PINs.
- wkat4242 3y ago
  The PIN doesn't have to be long because the key will block itself after a very limited number of attempts. Just like with your bank card. Extracting the key is another issue but the chips used in these are hardened. They are just like the secure element in phones.

throwaway892238 3y ago

Password managers have already made passwords obsolete. I literally don't know any of my passwords except my master one. Passkeys are an insanely overcomplicated solution we don't really need. Browsers just need a simple HATEOAS API for password managers to hook into, and web apps expose some HTML that triggers the browser. The password manager can then determine how to authenticate the user (however the user wants!), auto-inject the secret for that website, and the user is automatically logged in. E-mail reset if anything goes wrong. From the "we're a website that wants super fancy security" perspective, I get that they want something more complex. But there should be levels of security that the user can opt-in to. For example: most websites are fine with a simple password hash, assuming the password manager uses random passwords. Any website can implement that, every password manager can implement that, and it's better than 99% of regular users' password use today. So there's your baseline auth method. Then if you want something like TOTP, OIDC, public-key crypto, etc the server can advertise it, the client can opt-in to it, and authentication can continue. But not every site needs to implement it, and not every user cares to use it. Basically, we don't need every site and every user to use the most secure methods. We just need to make it easier to get a baseline of improved security, and allow people to slowly opt-in to stronger security.

XorNot 3y ago
Frankly I don't like the website getting to determine how I practice my own personal security: that's just the path of corporate lock-in, and it also has exactly one outcome - everyone will select either "maximum" because "that's secure" or "minimum" because "user experience". It's the worst of both worlds (i.e. the insufferable thing banks do where they try to force you to type in your password with the mouse).
dcow 3y ago
> Passkeys are an insanely overcomplicated solution we don't really need. This is simply not true. WebAuthN is not overcomplicated needlessly (I wouldn't even call it overcomplicated, it's literally just a signed challenge/response dance). It improves on Passwords+2FA in a few notable ways: 1. It prevents shared secrets from traversing the wire. 2. It naturally enforces that users are all using secure authentication keys without password rules nonsense. 3. It kills 2FA by allowing Relying Parties to request user presence verification as part of the primary challenge. 4. It is origin-bound which mitigates phishing. Passwords don't have any of these properties. And since your password manager handles the details for you, why wouldn't you want it to improve its implementation under the hood making things better for you with zero effort on your part?

amadeuspagel 3y ago

Physical security keys can have pins.

0x4e53 3y ago

Realistically, I don't think this will completely replace Yubikeys, nor do I think that only "security nerds" use them. In reality - the majority of leading organizations use Yubikeys to secure authentication across their company. While it's likely not as common for consumers, it is probably the most trusted solution in the enterprise today.

androidbishop 3y ago
you can use yubikey 5s as passkeys

ivlad 3y ago

> Passkeys are meant to be a password _replacement_, No. Passkeys parasitize on FIDO2 U2F standard, that was developed to be (as the name implies) the second factor. Resident keys are meant for on-device 2FA with PIN, a functional replacement of smart cards. Someone (Apple maybe) thought it’s a good idea to consider WebAuthn being good enough to be the only authentication factor (no resident keys, no hardware bond, keys are roamed via iCloud) but TouchID/FaceID protected on device. And they branded them as passkeys. > and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. You don’t. 2FA is not a goal on itself. The goal is to have user authentication that is protected from phishing, brute force and credential stuffing, and also not as hard to implement as smart cards. FIDO2 does that. The problem with Apple’s, Google’s or Microsoft’s implementations is not that they are less secure on a protocol level between the authenticating site and the user’s device, that’s exactly the same protocol. The problem is that the site has now to trust user’s personal account in one of these platforms and that the user did the right thing and also the platforms will always be doing the right thing - e.g., they will handle attacks on user’s personal account properly.

dwaite 3y ago
> Passkeys parasitize on FIDO2 U2F standard U2F authenticators and the U2F protocol cannot support passkeys. A passkey is a discoverable credential which supports user verification. U2F supports neither discoverability nor user verification. Passkeys as a user-facing term is meant to describe a user experience. Second factor authentication using U2F is a different experience. > The problem is that the site has now to trust user’s personal account in one of these platforms and that the user did the right thing and also the platforms will always be doing the right thing - e.g., they will handle attacks on user’s personal account properly. That is in fact how passwords work today. You can't tell if my password came from my head or from a excel spreadsheet printout I carry around in my wallet; from a cloud synchronized password manager or if I use the same password for every website which will accept it (otherwise, I will add exclamation marks to the end until it does).
NoZebra120vClip 3y ago

vaxman 3y ago

Passkeys combat phishing and sell mobile devices that have secure enclaves, tho the mobile operating software is apparently syncing the master key between devices enrolled in the same subscriber account. However, during MOST urban assaults, phone theft/damage is among the first thing to happen. It’s why all of this phone-as-token crud combined with FaceID are bad ideas that put convenience above security. The government should be pushing everyone into a federal SSO so that this is not needed and so they don’t need to worry so much about encryption.

heavyset_go 3y ago

> Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. Hardware security keys that implement FIDO2 UAF can be protected by PINs/passwords or biometrics, the former being "something you know", and the latter "something you are", with the security key itself being "something you have".

thayne 3y ago

Which is why the author mentioned using a pin or biometrics to unlock the hardware security device.