15 ms·

Passkey technology is elegant, but it's most definitely not usable security

• high_5 2y ago
  Passkeys deployment reminds me of a cartel agreement among FAANG without the actual coordination. It's too good of a new tech frontier not to colonize.
• freetonik 2y ago
  In some parallel universe, each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys). Instead of "many cooks" mentioned in the article, there is one standard. I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc. I already have a universal solution for credentials: 1password, which is cross-platform. With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer. But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same. Like with many other solutions, the current approach with passkeys is designed for an imaginary "user in vacuum" model each company dreams about, where people are 100% into one ecosystem, forever.
  • YPPH 2y ago
    >But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs You can't save your personal passkeys on your work phone and vice versa, but when logging in to a service on one device, you should be able use a passkey from the other device via Bluetooth by scanning a QR code.
    • freetonik 2y ago
      Good to know, thanks! But I might not have the other device on me at all times.
      • asah 2y ago
        FIDO keys are tiny e.g. yubikey 5c
        • lxgr 2y ago
          If anything, this achieves the opposite of making sure I always have mine on me. Dedicated, external hardware authenticators are great for logging in to very high value accounts or password managers, but arguably they're not really viable for 99% of users and use cases on a day-to-day basis.
          • nixosbestos 2y ago
            I don't agree at all. It's on my keychain, next to my keys, a nice symmetry. When I need to login I hold it to the back of my phone for half a second. It's incredibly easy and would be even easier if it weren't for the UX presented by iOS, Android, and Windows where they try to be the provider. Android has gotten a bit better. Windows is the worst about it afaict.
            • lxgr 2y ago
              Different people, different preferences. I don't like having to fetch my keys when I'm at home at all, which is where I do most of my authentications. I'd have to get up, walk to where I usually keep them, walk to my computer with them to authenticate, and then either walk back or forget the keys somewhere in the house and have to search for them when leaving (or detach the authenticator from the keychain and then not have it on me when I'm leaving). That's why I don't like using USB authenticators on a regular basis.
              • 2y ago
  • gchamonlive 2y ago
    Honest question, this isn't supposed to be a burn in any sense. But isn't it contradictory to want to know how and where your credentials are stored and use any credential management solution that isn't opensource and selfhosteable?
    • freetonik 2y ago
      Fair enough, but I believe there is a spectrum between "I don't want to know things, let them just work" and "self-host and manage an application for storing the most sensitive type of information". 1Password is neither opensource nor self-hostable, and it stores data in the proprietary cloud (at least exports are easy). But I understand that and accept it. If I get a Macbook, an Android phone, and a Windows PC (a very popular combination of devices, btw), I honestly don't have energy to investigate how to inter-operate their passkey solutions. From the get go, I assume it's gonna be either impossible, or very hacky and fragile. Maybe I'm wrong, but last time I checked I simply walked away thinking "nope, no passkeys for me".
      • Aaron2222 2y ago
        1Password itself has native passkey support. I don't have experience with it on mobile, but on desktop browsers their extension overrides the build-in passkey support to use/store passkeys from/in 1Password (with a button to fall back to the built-in implementation for its storage, hardware tokens, QR code to use/store a passkey from/on a smartphone, etc).
        • Aaron2222 2y ago
          Looks like on iOS it integrates with the native passkey support (so is usable anywhere native passkeys are supported). 1Password on Android looks to have similar integration, but only for apps at this stage (not websites, due to an Android limitation). So still a little while to go yet for "it just works" across all platforms.
  • _Algernon_ 2y ago
    >In some parallel universe, each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys). Instead of "many cooks" mentioned in the article, there is one standard. Ignoring site support, this exists. It's called USB and yubikey.
    • anotherhue 2y ago
      Was called a SIM card before that.
      • formerly_proven 2y ago
        Both are smartcards. Yubikeys also happen to support the USB HID CTAP protocol, which is something unprivileged applications can usually talk to directly on most operating systems. Most other CTAP transports are just smartcard transports (APDUs over PC/SC or NFC). Yubikeys also have a PIV applet, which isn't used for your typical enterprise X.509 PKI, and an OpenPGP applet, which typically isn't used.
      • lxgr 2y ago
        PIV, GnuPG, or PKCS#15 are probably better comparisons. SIM cards use symmetric cryptography, which means you can only authenticate yourself to a single entity.
    • deleted 2y ago
      [deleted]
    • JumpCrisscross 2y ago
      > this exists. It's called USB and yubikey An extra physical device is a non-starter for mass adoption.
    • Too 2y ago
      Having a big dongle sticking out of your iPhones lighning port is completely impractical, compared to using the integrated TPM backed storage, unlocked by face-id. Yes there are smaller dongles but only for usb-c and i still don't want to fiddle with it when charging. It's only a matter of time before desktops gain the same secure key storage as our phones do, add a hardware key to prove physical presence and then yubikeys are obsolete. The only future for yubikeys is for temporary transfer of keys under wrap between devices, where you don't want to use a cloud service for doing so. While an open api with replaceable internals is a nice idea and one that enabled yubikeys in the first place, once this is integrated in the SoC and the OS, there will be little need for alternative storage backends. What's more pressing now is pluggable synchronization of secrets, for those who don't want their choice of cloud provider to be bound to their choice of OS, or for those who rather synchronize entirely offline through a yubikey.
  • mihaaly 2y ago
    > With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account And from this account you may be locked out for various reasons anytime, as it happened to countless persons previously, violating exotic or even understandable rules, or just been in the crossfire of some galactic corporate incompetence (some f'd up), but this way you'd be locking yourself out of everything especially if you were that user in the vacuum, exposing yourself to the mercy of a single organization with changing managemenet and incentives as the wind turns in a city's dense downtown.
    • skybrian 2y ago
      I solve this by creating two passkeys for each account, for iOS and Chrome. This covers all the devices I might use to log in and there’s no single point of failure.
      • HumanOstrich 2y ago
        That doesn't solve anything. You just have twice as many problems now.
        • skybrian 2y ago
          What are you talking about? Redundancy is how you avoid getting locked out. Each passkey serves as a backup for the other one. More generally, you should have two keys for any lock, so you can still get in if you lose one of them.
          • michaelt 2y ago
            Setting up both Apple and Google passkeys solves: * Lost access to your Google account, but still have access to your Apple account (or vice-versa) * Apple device doesn't support Google passkeys, or vice-versa But it multiplies the following downsides: * Apple/Google account gets hacked, hacker gets all your 2FA credentials * Snooping on your activity. Particularly Google, but Apple also have an advertising business. * Setting up accounts on new sites is twice the hassle. * Too complicated for the kind of folks who need the phishing protection passkeys provide.
  • paxys 2y ago
    > I already have a universal solution for credentials: 1password, which is cross-platform. You can store passkeys in 1password so they work everywhere.
    • NikolaNovak 2y ago
      The article is 80% about friction and confusion in trying that solution - from confusing prompts and endless questions designed to wrestle control over to local ecosystem, to use cases that just don't work with external vendor as opposed to native platform owner :-(
      • lxgr 2y ago
        Which use cases don't work with external implementations, but do with the first-party one? I have yet to encounter one on iOS and macOS.
        • pas 2y ago
          https://github.com/keepassxreboot/keepassxc/issues/10374 https://github.com/keepassxreboot/keepassxc/issues/10374 Passkeys not working on certain sites I suspect 1password also has at least a few sites that need special handling
    • onetwothreepass 2y ago
      But 1password forces you to install the browser extension to do this.
  • ElFitz 2y ago
    I don’t know about 1password, but proton pass supports passkeys, on both iOS, Safari & Chrome (and probably others).
    • freehorse 2y ago
      I use proton pass and have the same issues as the author. Whenever macos/ios is in the mood it lets me use it to store passkeys, else it is an endless maze of bugs and confusion. Proton pass supports passkeys but the OS does not always let it communicate with the website.
      • lxgr 2y ago
        Any chance that this is actually due to websites requesting weird WebAuthN credential parameters (e.g. enforcing attestation, which software implementations by definition will not be able to support) or using the legacy U2F API? In my experience that's usually the culprit.
        • freehorse 2y ago
          No idea. I do not have the technical knowledge neither the time to check sth like that. I am totally clueless even as to where and how exactly passkeys are stored in my computer. For me they just work until they don’t. It does not really help in trusting them as password replacement.
  • loloquwowndueo 2y ago
    Pretty sure 1password can store and use passkeys.
    • sigzero 2y ago
      It certainly can.
      • 1oooqooq 2y ago
        until the time comes that it's used for spammers and everyone requires providers from a list that only included apple and Google. y'all trying very hard to not see where this will go.
        • lxgr 2y ago
          This would be possible via attestation, but both Apple and Google removed that feature when they replaced their respective device-bound authenticator implementations with cloud-synchronizing ones. (Google technically still allows creating device-bound ones and supports attestation in that case, but that's arguably a niche use case and not what people are talking about when they say "passkeys".)
    • onetwothreepass 2y ago
      It does, but 1password forces you to use the browser extension in order to manage passkeys. I still don't trust browser extensions. I'm probably being irrational, but it is hard to find good sec info on how "safe" extensions really are.
      • Arnavion 2y ago
        If you're copy-pasting passwords from 1password into your browser you're making yourself vulnerable to phishing. The browser extension's autofill will at least check the domain name and prevent that.
        • pletnes 2y ago
  • grahamj 2y ago
    I moved away from 1P some time ago due to their move to a subscription model. After trying other solutions and having high hopes for Apple finally shipping a passwords app I finally decided to move back this year. It's costly but excellent. I have several accounts shared with my wife and was getting caught up in the passkey problems you mentioned. Even though 1P handling OTP is not really 2FA it's very convenient and still more secure than no OTP. I also don't always want to have to have my phone on me. On top of that I like knowing that if I change my mind at some point I can export my credentials. Moving my iCloud keychain creds was an eye-opener: it felt purposefully painful. You can do it but much of the metadata is missing or lost in the process, with the titles being the URLs. Yuck.
    • ramon156 2y ago
      Switching from 1p to icloud makes sense, but there's a decent chunk that isnt in the apple ecosystem. I'm keeping 1p for now, I'd even argue that the price is pretty good, especially for families.
      • grahamj 2y ago
        To be clear I never used iCloud/keychain exclusively, but my wife did and I performed the migration from that to 1P.
    • onetwothreepass 2y ago
      I prefer to pay for something as important as a password manager. It's like some people get excited about all-you-can-eat sushi: sorry, but raw fish isn't something I want to go super-cheap with.
    • apitman 2y ago
      Have you tried bitwarden?
      • grahamj 2y ago
        Yep that's mainly what I used. I trust it and it has a good feature set but the UX is just not up to snuff imo. I could get by with it but no way was I going to roll it out to my less techy family members. 1P is just much easier to use and more polished.
  • lxgr 2y ago
    Using 1Password as your passkey backend seems like it would solve all the problems you're describing, except that passkeys are (for the time being, at least) locked in to 1Password [1]. It works on multiple OSes (as a native passkey backend on iOS, via browser extensions providing WebAuthN on all major OSes) and isn't tied to your Apple ID. If you care a lot about exportable passkeys, Bitwarden (and Vaultwarden) can export them. Not sure if any other implementation can import them at the moment, but the data looks portable enough (i.e. it contains the ECDSA private key and all other client properties required). [1] https://support.1password.com/save-use-passkeys/ https://support.1password.com/save-use-passkeys/ mentions that "Passkeys saved in 1Password can’t be exported at this time."
    • radlad 2y ago
      1P will support it in a standards-compliant way soon: https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk... KeePassXC also supports export but not yet using the aforementioned standard: https://github.com/keepassxreboot/keepassxc/issues/11363 https://github.com/keepassxreboot/keepassxc/issues/11363
      • maeil 2y ago
        > 1P will support it in a standards-compliant way soon: https://blog.1password.com/fido-alliance-import-export-passk https://blog.1password.com/fido-alliance-import-export-passk... See then believe, in the current environment saying "soon" based on 1password submitting a draft is much too optimistic, given the big interests Google and Apple have in neutering this possibility.
    • sheepybloke 2y ago
      Same, I use bitwarden and it keeps all my passkeys in it and is available on all my devices.
    • bobbob1921 2y ago
      I’m not saying I’m against 1pass adding the ability to export passkeys from 1Pass, however, doesn’t this increase the possibility of your computer is compromised (say remote control) and now your passkey is exported / moved to a new device and hacker auths in via that new device? (versus with a hardware passkey which cant be exported electronically)
  • pcl 2y ago
    ”But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.” Apple has recently addressed this. You can now create shared groups, and selectively assign passwords and passkeys to the groups. You could easily create a group with your two identities and move the credentials to that group. https://support.apple.com/guide/iphone/share-passwords-iphe6b2b7043/ios https://support.apple.com/guide/iphone/share-passwords-iphe6...
    • antgiant 2y ago
      Beware of the hidden catch here. The account that adds the credential to the group “owns” it. So if that account goes away for any reason so does the credential.
  • mcshicks 2y ago
    Like this https://www.congress.gov/bill/118th-congress/senate-bill/884/text https://www.congress.gov/bill/118th-congress/senate-bill/884...
  • efitz 2y ago
    I think that we should consider passing a law that a vendor may non disable “log in with” and supporting functionality like password recovery, for a user account for some lengthy period of time after involuntary termination of the user. But I think that the bigger issue is that I don’t think that large corporations should be allowed to disassociate with their users except in the case where criminal activity against that company is involved. This is especially important now that all the vendors want ecosystem lock-in AND have ToS that allow them to cancel pretty much arbitrarily.
    • bobbob1921 2y ago
      Agreed, and some kind of appeals process/ external arbitrator, if your account is terminated due to terms of service or automation.
  • gwbas1c 2y ago
    > is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys) Wow, that will immediately become a prime target for hackers / phishers.
    • CamperBob2 2y ago
      So?
      • gwbas1c 2y ago
        Then we're getting to a point where the proposed law weakens passkeys to the point where they are much ado about nothing.
  • throw0101d 2y ago
    > I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc. There is a draft standard in the works for export/import: * https://fidoalliance.org/specifications-credential-exchange-specifications/ https://fidoalliance.org/specifications-credential-exchange-...
  • joe_the_user 2y ago
    each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys) Indeed and that law would provide overrides for the state. And which state, you might ask? All of them? The state where the device is manufactured? Hmm...
  • exabrial 2y ago
    That was called "U2F", but we made it "better" with PassKeys!
  • deleted 2y ago
    [deleted]
  • crooked-v 2y ago
    > their single, universal, transferrable set of security credentials (like passkeys) That's an awful idea. Normal people already have a nightmare of a time with getting locked out of accounts, and now you want their entire lives to depend on a single hardware fob that can get lost?
  • musicale 2y ago
    > With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer. iCloud Keychain/Passwords works on macOS and Windows, and there are extensions for Chrome and Edge. I don't know whether it works with passkeys though. > But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same. As I understand it, Apple's BYOD support allows you to have a managed/corporate Apple ID and a personal Apple ID on the same device. You can also add a managed Apple ID to a personal device like an iPhone; on iOS (and possibly macOS?) it isolates the data between them so that corporate apps can't access personal data and vice-versa. I believe it's possible to have multiple accounts with separate Apple IDs, and I think it is possible to add "secondary" Apple IDs to a single account, but I don't have experience with this.
  • mystified5016 2y ago
    Passkeys are the ideal identity management solution for spherical users in a vacuum
  • Mandatum 2y ago
    > But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same. By design. This is what caused the ZenDesk, Atlassian, Disney and Sony hacks.
• trollbridge 2y ago
  Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.) Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.
  • growse 2y ago
    > Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.) Does this mean that any HSM where inability to export the private key is a feature is also doing it for "vendor lockin" reasons?
    • redserk 2y ago
      If you’re buying and implementing a HSM, you really ought to understand this concept. After all, you’re getting paid to. I do not expect random consumers to understand this concept. It’s grossly irresponsible and is simply user abuse. I love Passkeys. They’re fantastic. I do not love how unportable the implementations for Average Joe and Jane are.
    • fireflash38 2y ago
      It's both. Most of those vendors have ways to backup those keys securely to same vendor backup product. But they won't let you export them via a wrap or whatever. It functions both as a security feature and a vendor lock in.
      • EvanAnderson 2y ago
        It's absolutely vendor lock-in, first and foremost. It happens to align with security. I did a project 10 years ago to sign firmware for embedded devices w/ a planned 25 year product life. I spoke with two different HSM vendors. Both said the Customer would be able to backup and transfer keys from one HSM to another. Both also said that was applicable within their products only. There was no mechanism to switch to another HSM vendor (and neither offered a contingency to get the keys out if the vendor ceased business operations). Apparently this situation has gotten no better in the last 10 years: https://www.icann.org/en/system/files/files/hardware-security-module-replacement-2024-28feb24-en.pdf https://www.icann.org/en/system/files/files/hardware-securit... > In April 2023, IANA became aware of the decision by the manufacturer of the Keyper PLUS HSM – the equipment used to store private key materials for the Root Zone KSK – to cease its production of the device. Furthermore, the manufacturer will offer no successor product. That's ridiculous. There should be a standards-based protocol to transfer key material between HSMs. It should be tied to physical access using physical tokens. Make the protocol baroque and difficult. Heck, even make it a requirement the source HSM has to to be physically destroyed to complete the process (to prevent "cloning" attacks). For USB authentication keys this level of cloak-and-dagger LARPing is stupid. There should be a method to export and encrypted copy of the contents of my USB token and, worst case, import it into another token manufactured by the same provider. ("But cloning!" Fine-- tie it to registering the token with the manufacturer along with real-world identity verification. Make it a premium service with an associated cost, if that's what it takes.)
• thefz 2y ago
  [flagged]
  • recursive 2y ago
    One problem with your proposed title is that "etherogenoeous" doesn't seem to be a word. Even it is, approximately no one is likely to know what it means.
  • sunshowers 2y ago
    The article is quite good, and as someone who uses passkeys I feel it. So far I've only been using them as a convenient alternative to passwords (passkeys go right next to passwords in 1password), and I plan to keep using them that way.
• bigbacaloa 2y ago
  [dead]
• jmclnx 2y ago
  I will never use Face ID or Fingerprint for any device, but I agree, passkeys are a bit too much. Also, the OSs I use may not support passkeys. They are not on the list.
  • lxgr 2y ago
    Your OS doesn't need to support them; browser extensions can implement them too.
    • Gigachad 2y ago
      OSs should add support though because it lets desktop apps auth without having to open a browser login page.
• eigenspace 2y ago
  While I agree with many of the points raised by the author, I guess I just had much much more pessimistic expectations than they did. If I were to write an article on the topic, I'd probably end up listing the exact same factual information, but with the opposite spin: "This is progressing much quicker and more smooth than I would have anticipated!" Switching from passwords to passkeys is a big change in the entire security model of the modern user-facing internet. We shouldn't be at all surprised that people are both cautious and opinionated about how it should be done, how to migrate users, and how to deal with fallbacks. Yes, the current situation is one that is messy and not significantly more secure than the previous status quo, but the direction of travel seems at least promising. I wouldn't actually want my bank to overnight decide that passkeys are the way to log in, and if I use a passkey there should be no insecure fallback options. I want my bank to roll out a passkey, and figure out the infrastructure around it, probe for problems, and allow fallbacks that are equivalent to their previous systems. Similarly, I wouldn't want every passkey management implementation to instantly coalesce around one specific set of management practices and UX. I want various ideas to be tried out and see what comes out of it, even if some of those experiments are bad.
  • Schiendelman 2y ago
    The article you would write is the right article! But it wouldn't get shared and make the first page of HN. It's entirely possible people have written exactly the article you want, but our discovery mechanisms are all based on aggregate emotional reaction.
• growse 2y ago
  Lots of criticism in the article, some of it valid, none of it constructive. Sure, there's UX problems as we're still trying to figure out what good looks like here. But in the absence of specific, concrete suggestions about how we improve usability for unphishable credentials, it seems that passkeys are a pretty good go. Perfect? No. Better than passwords? Undoubtedly.
  • saagarjha 2y ago
    The point of the article is that they are not actually better than passwords in a lot of ways that people actually want them to be better.
    • growse 2y ago
      One of the primary, explicit design goals of webauthn is that they're not phishable. Passwords are phishable. What are the other ways that people want passkeys to be better?
      • saagarjha 2y ago
        They want to share them across devices, sometimes even devices made by different vendors. They want to hand a passkey to a family member or friend. They want to not be concerned they will lose the passkey if the device they are on is lost. They want to understand what the passkey is actually doing for them when they log in, rather than it sometimes being both the username and password, sometimes just replacing the password, and sometimes becoming a sort of weird second factor thing. They want to know how they can change their passkey. The rollout of passkeys leaves a lot to be desired.
        • growse 2y ago
          I don't disagree with you about the UX. It could be better. It could be worse. What's your proposal on what a better UX might look like (along with getting everyone to adopt it)? > They want to share them across devices I do this today on Bitwarden, Apple users do this today with Keychain. Who's the "they" here? > sometimes even devices made by different vendors. > they want to hand a passkey to a family member or friend ..... Why? What's the use case here? Tying a credential to a single identity (and therefore, human) is another explicit design goal of webauthn. I seem to remember the original proposal was that locking a private key to a device in an unextractable, un-copyable way was an explicit benefit - if it can't be exported, then it can't be stolen/copied without the device also being stolen. This was softened with the purpose of allowing syncing amongst devices that already have a good story on sharing sensitive data, but this mechanism does not exist generically. There is no standard way, right now, that my iPad and Pixel device can share a private, sensitive piece of information without the help of a 3rd-party syncing provider. Without that, cross-platform credential sharing can't exist out of the box by default.
• cypherpunks01 2y ago
  Anyone know what adoption rates for passkey looks like now? I think they are cool too, but the constant prompting to create them and invisible/variable UI everywhere is a problem. It presents as inconsistent as compared with the standardized username/password form that grandmas understand.
• eadmund 2y ago
  > And forget about trying to use a passkey to log into PayPal on Firefox. The payment site doesn't support that browser on any OS. I had no idea! That’s pretty awful. > Somehow, the mysterious entity responsible for this message (it's Google in this case) has hijacked the process in an attempt to convince me to use its platform. I do not want Google to be managing my passkeys or passwords. Even if they promise to keep them device-local, I frankly don’t believe them: the temptation to make it easy for users who have lost a device or forgotten a password is too strong, and at some point they will take the plaintext, and then it is game over as far as security is concerned.
• ballenf 2y ago
  I don't know. If you're in the iOS ecosystem and using iCloud syncing and Safari things are super easy and default more secure than without passkeys. The author's examples of Firefox, chrome, a password manager and a physical key apply to very technical users who seem quite capable of navigating the complexities he complains of. The vast majority of people are just not going to encounter most of his issues. I sympathize with his issues, but he's kind of complaining that fighting the ecosystem is complicated. My guess is that <<1% of people use his combination of multiple browsers a non-iCloud pw manager and a physical key on MacOS. And they're not substantially less secure than his setup. My only issue with passkeys is sites that don't seem to have them figured out yet. They'll let you setup a passkey but then offer to let you sign in with a password first. These seem to be becoming more rare, but even amazon's passkey seems random when it lets me use it. And even then it wants to send me a text message code anyway (this is probably a setting somewhere, so my fault I'm sure).
  • hkpack 2y ago
    > They'll let you setup a passkey but then offer to let you sign in with a password first. I am not sure if that is what you're talking about, but the standard way to implement login with passkeys is to use a normal username/password form and leverage the auto-fill mechanism to offer you to sign with a passkey if it is discoverable. Another way is to have a two-step login, where you enter your login/email in the first step, and then use passkey to login in the next. There are benefits and drawbacks in both of them. Also, passkey can be used with multiple authenticators (like Yubikey), and most popular websites consider that verification of the user is not implemented sufficiently for some of them to be used as the only way of authentication, so they don't allow you to login with them without a second factor (i.e. password).
• sneak 2y ago
  It gets worse. U2F keys were stateless, the site key pair was stored by the site (encrypted to, and by, the u2f key). Now, passkeys are stored in the device, and, you guessed it - they have a limited number of slots. The fido2 situation is really bad.
  • ttyprintk 2y ago
    25 on my YubiKey. Would 100 be enough?
    • Borealid 2y ago
      A Yubikey purchased today actually allows 100 discoverable credentials. Keys running older firmware stored a max of 25.
      • ttyprintk 2y ago
        Thank you
      • FireBeyond 2y ago
        If you don't get old stock - wasn't there some issue recently where they were still selling Yubikeys with the known vulnerability saying that "unless you knew about the vulnerability and specifically had a need to avoid it and told them", that that wasn't a problem?
    • lxgr 2y ago
      Both are awkward in that I could reasonably expect to exceed them in the lifetime of a hardware authenticator. The ideal number would be infinite and is in fact very achievable with a very small API modification, but alas, the WebAuthN working group didn't consider it necessary: https://github.com/w3c/webauthn/issues/1822 https://github.com/w3c/webauthn/issues/1822
    • jlokier 2y ago
      I have about 1000 accounts in my password manager. 100 passkeys to replace them is not enough. I wouldn't feel comfortable with that as a hard limit, if it's to replace all passwords. Many of those 1000 are obsolete (old accounts I'll never use again), but many are not. At least 30 are things I use every week, most of them financial or tech admin, i.e. not social media. I'm confident (though not certain) that I login to more than 100 accounts over a typical year, and there are accounts that I sometimes login to more than a year since the previous time, glad that I recorded the credential.
• mongol 2y ago
  I haven't used passkeys, I have not been prompted about it, asked to create one, been reminded to change to it, or anything like that. It is like they don't exist to me. Am I supposed to be nagged about it in order to change to it? Or is it something you have to hunt for in the account details of a site? Unsure if I am a late adopter or if the technology has not found me yet.
  • throwaway894345 2y ago
    Google, GitHub, and a few other services have bagged me to create passkeys. I haven’t tried hard to understand how to use them, but at some point I created one on one device and whenever I try to log in from a different device it doesn’t work but passwords and MFA work just fine across devices so I mostly just ignore it. Annoying that a lot of services are pushing passkeys as the default mechanism though.
    • mongol 2y ago
      Did you use 2FA before? I use it, possibly they deem my security good enough because of that?
• the_clarence 2y ago
  I moves to an android phone to buy a folding phone and I lost all my passkeys. Its a nightmare
• Borealid 2y ago
  The article author skirts around the key true observation here, which is that passkeys were a great idea until cloud vendors waged war on hardware keys. The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise. The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise. The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article. The ideal future state is: * the provider for newly registered credentials would be a browser setting * the setting would come configured to use the OS vendor out of the box * installing a password manager providing passkeys would prompt to change the setting to use the password manager instead * one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option * there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience. The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.
  • fastball 2y ago
    What is the benefit to Apple?
    • neogodless 2y ago
      Doesn't Apple primarily want the best user experience, and the safest way to use devices? So they should get onboard with what is best for the user.
• frereubu 2y ago
  TOTP suffers from a similar issue - I use 1Password to store my TOTP codes, but both Google and the UK's HMRC tax website talk about using their own apps for codes rather than anything agreed like "one-time passwords". The digital world is rife with this kind of jockeying for position through language. It took me far too long to understand that "podcasts" are just mp3 files from an RSS feed. Likewise, in the heyday of interactive TV in the early 2000s, when it was going to conquer the world because everyone had a TV but not a computer, an agency I worked for were invited for a demonstration of a choose-your-own-adventure game they were developing. They kept referencing a "carousel system" where all pages were sent in a looping system and when someone made a choice it waited until that page came round in the "carousel". I kept asking whether that was like Teletext - https://en.wikipedia.org/wiki/Teletext https://en.wikipedia.org/wiki/Teletext - but they absolutely refused to say that and kept saying "well, it's a carousel system". This refusal to deal in everyday language, alongside trying to get people to use their own apps / sytems, really hinders the adoption of useful technologies.
  • ffsm8 2y ago
    [flagged]
    • xethos 2y ago
      I'm not going to dictate MP3, but yes: podcasts absolutely are an audio file pulled from an RSS feed. Your description covers some podcasts, but not every podcast has video (which should be entirely optional if it's there at all, and frankly makes it less of a podcast in my opinion), and many go through some pretty heavy editing, even if just to balance audio levels, prune dead conversational branches, and remove filler words or dead air.
      • Izkata 2y ago
        Part of it is right there in the name: "pod" came from iPod. The device that was audio-only.
    • hoherd 2y ago
• samcat116 2y ago
  I seem to be in the minority of HN users that love passkeys. I use them for any login that I reasonably can. When creating a passkey I create one in iCloud Keychain as well as in 1Password. I do agree that there needs to be a better import/export story, but I have confidence that will come.
  • aednichols 2y ago
    Same. It is annoying to dodge the prompts that guide me to save in Chrome or iCloud instead of 1Password, but with patience I have always succeeded. Of course, I know what I want and when to ignore what the machine suggests, which I wouldn’t expect of non-enthusiasts.
  • SXX 2y ago
    I would even get idea to make passkeys non-exportable, but lack of import feature for me as power user just kills passkeys for me.
    • Gigachad 2y ago
      There is a draft spec for transferring keys between password managers. It's complex because they don't want to make it possible to have your passwords dumped insecurely on your computer. But to have them transferred directly between credential stores securely.
  • jeroenhd 2y ago
    Same here. My passkeys are in Bitwarden and they're more complex and secure than any password websites will let me enter. I don't trust cloud providers like Google and Apple to keep my secrets for me, but with Bitwarden I can just dump the secrets and load them from a backup if I wish to do so. I've also been pleasantly surprised at how well logging in through CTAP2 works. Any laptop/desktop PC with Bluetooth can use the Bitwarden vault on my phone (after unlocking it with a password, of course) to log in with very little hassle. Much better than copying over passwords, or opening the password vault on every PC I need to log in to something.
  • Too 2y ago
• fredfoo 2y ago
  I think the elephant in the room is the total lack of website/framework/library support Fido has. Trying to implement support on any random site is about as insane as rolling your own crypto and having the single sign on bolt on is sort of how people selling FOSS+enterprise want it. The end result is that it was more a standard for them more than for direct use by the little sites, and password managers getting involved only furthers that enterprise industry standard feel.
  • WorldMaker 2y ago
    Yeah, it has been frustrating me lately that there isn't a simple drop-in Passkeys-only library/framework yet. Right now the best advice is "use Auth0/Okta or competitor and configure them in Passkey-only" which adds a vendor where you shouldn't need a vendor. The other day I just wanted to store passkeys in Deno KV without feeling like I was rolling my own crypto library. I did not succeed in the limited amount of free time I had on that personal project, and that seemed a shame and a half.
  • shim__ 2y ago
    It's rather simple actually: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent..., no crypto involved
    • palata 2y ago
      Unfortunately, that's probably way too technical for most developers nowadays, who are almost proud of not being able to read a manual.
      • jeroenhd 2y ago
        That's just the browser client part of the equation, this says nothing about the server side. The `challenge` part of the API, as well as storing and maintaining the necessary public keys and doing the actual validation of credentials, are left for the reader to implement in the backend. The browser API makes it easy to program a client against passkeys, but that doesn't necessarily hold up for doing the server implementation. For that, you need to either find a library that matches your requirements, or read through guides like these: https://developers.google.com/identity/passkeys/developer-guides/server-authentication https://developers.google.com/identity/passkeys/developer-gu... that skim over a lot of details.
• cchance 2y ago
  Why is it defaulting to passkey if i want to use a security key... probably because 99% of people will be using the builting apple passkey and not a third party hardware device that few have... hence why the hardware device is considered "other"
  • mixmastamyk 2y ago
    It's not merely a default, but a desire to punish outliers to conform.
• shreddit 2y ago
  As an Apple ecosystem user i really like passkeys. I don’t have to remember passwords and once i set up a passkey on a device it’s synced to all my other devices. It’s just really convenient.
• EPWN3D 2y ago
  This piece reads very nitpicky, and I just don't identify with what it's saying. My use of passkeys in Safari on Apple platforms has been basically seamless. I guess if you use tons of different browsers on tons of different platforms and want to work in hardware tokens, it's a pain, but most people aren't doing that. The problems highlighted are real, but they don't rise to the level of "Passkeys aren't usable security". For users that would have otherwise not opted into 2FA at all (or don't know how to set up TOTP), passkeys are fine. I'm sure there are some warts to iron out, but they have to be evaluated within the context of the practical alternatives, not the context of the author's own personal security priorities.
  • wyattblue 2y ago
    I think you're downplaying real concerns people have. Having two different devices is not an exotic scenario
• jbverschoor 2y ago
  It’s invisible. A black box, non transferable. There’s no mental model that maps and you can’t back it up as a normal person. Implementations are half baked and still require all the rest, all the attack surface is even larger. Was super excited, totally not anymore.
• NelsonMinar 2y ago
  I think passkeys are a failed product. Time to give up and start over again. I don't say this casually. I have been arguing for ending passwords for nearly 20 years now. I'm a software engineer and broadly understand a lot of security protocols. I spent hours understanding passkeys and figuring out how to use them in my environment. The core idea is great! But the usability is garbage. I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me. All passkeys do now is clutter up the one login flow that works for me (1Password form filling, as awful as that is.)
  • lxgr 2y ago
    > All passkeys do now is clutter up the one login flow that works for me You can always disable that in the settings with one click. > I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me. I can't speak for how bad things are on Windows, but my flow on macOS (Firefox) and iOS (Safari) is the following: - Try to set up a passkey at a site offering them. - Log out and attempt to log back in using the passkey. If it works (and it does for 80-90% of all sites), great, use it in the future! - If it doesn't work, delete the passkey, make a mental (or actual, in the password manager) note that the site has a broken implementation or very bad user experience, for future shaming in threads such as this. (Hi, Amazon and Paypal!) Obviously that's not viable for non-technical users, but it does save me a lot of time in the long run, since every subsequent login is so much faster than using whatever second factor sites are requiring me to provide otherwise.
    • Groxx 2y ago
      >Log out and attempt to log back in using the passkey. If it works (and it does for 80-90% of all sites) ... and right there is a big part of the reason I distrust the current passkey implementations. That's an absurdly low success rate, and I see similar numbers echoed by many people who use them, regardless of the site's importance to their life or apparent technical ability. (my own dabbling has an even worse success rate, though I've somehow managed to dodge multiple complete-passkey-data-loss issues in clients) And for some reason it doesn't seem to be getting much more consistently working either.
• thefreeman 2y ago
  As a technical user who understands how these work and has none of the confusion issues the author describes, my biggest problem and the reason I stopped using them for google is they seem to arbitrarily set the session length for passkey authenticated sessions much lower. I found myself needing to reauthenticate with google every day or 2 when signing in via pass key. I assume the developers thought this would be seamless, but it is a very annoying interruption to workflow. Especially since I use 1password as the backend with my laptop screen closed it results in me needing to type my (long and complicated) password manager password every time and usually when I am trying to access something timely like a meeting invitation.
• deleted 2y ago
  [deleted]
• wnevets 2y ago
  Forcing a new key pair for every single website was a mistake. If the crypto is secure than a single key pair should be suffice. That is how we use public key crypto almost every other use case and we get to avoid vendor lock in completely.
• whartung 2y ago
  Maybe someone can explain it better to me. It seems that the primary goal for passkeys is to eliminate password fishing. You still need a password for the site. Even with passkeys, you can still login with a password, either from a different machine, or, if nothing else, to recreate your passkey. But passkeys offer a bit more security to enforce that you're actually sharing the credential with the proper site, correct? Am I missing something? I mean, there's the whole syncing passkeys across stuff, but that's all optional. There's no requirement for that. You should be able to configure multiple passkeys to the same site across your various machines (for whatever reason), right? And I assume the sites won't "auto login"? Even with a passkey you would need to (potentially) hit a login button or something. I just want to make sure I understand it clearly.
• amelius 2y ago
  After reading 1/2 of the article, I still have no idea what a passkey is.
  • mixmastamyk 2y ago
    My understanding: It's like a yubikey (a device that lets you login securely) but using a similar protocol without the hardware. "Virtualized" in other words. Unfortunately susceptible to poor self-serving implementation UI by greedy vendors.
  • alfiopuglisi 2y ago
    In my limited understanding, they are similar to SSH public/private key pairs. But the details continue to elude me, no matter how much I read about them. Won't try them out until I get how they work.
    • lll-o-lll 2y ago
      It’s that, except the OS manages the private key (in a “secure enclave”). So you, the user, (or malware), never get access to the private key. The second crucial part is that these private keys are cloud synced. This means that the average Joe doesn’t lose their passkeys when they lose their phone. Get a new phone, and it will sync your passkeys and you are back. For people in the Apple ecosystem, it really is a straight upgrade over passwords. Where it sucks: - I’m not comfortable trusting a big vendor with the keys to my digital life - I only have one device, so when I lose that device I’m locked out till I get another - I want to use my own password manager to handle passkeys - I am in multiple big vendor ecosystems - I want to export these private keys (this one is sort of coming, the standard has been defined to allow export and import, but again in such a way that the user (or malware) cannot access these private keys)
      • alfiopuglisi 2y ago
        Thanks for the explanation, it was very clear. Especially the bit about never being able to see your own private key. Ok I get it, it's to prevent malware from doing the same, but it still vaguely distasteful.
• samgranieri 2y ago
  I'd like to just keep using security keys, thank you very much. They are much simpler and easier to understand and explain.
• ilaksh 2y ago
  I like the idea of using a password manager, but I think we should be aware that can create a single point of failure. For example, the LastPass breaches.
• NelsonMinar 2y ago
  This article links to a bunch of pages at FIDO Alliance, the official passkey info source, pages like https://fidoalliance.org/fido2/ https://fidoalliance.org/fido2/ FIDO Alliance's website is pure garbage. On first load all the content is covered by a demand you "sign up for updates!", a modal blocking the rest of the page. Also there's a surveillance consent popup that opts you in to tracking. It takes 9.9MB to load this content-free page. Closing the distractions so you can read the content loads another 3MB. Why would I trust this alliance for anything to do with website creation?
• vinay_ys 2y ago
  The most common lock and key ergonomics that everyone is familiar with is the following: 1. You have a lock, you have a corresponding physical key. You can have more identical physical keys. All of them will unlock the lock. If you lose the physical key, you can call the locksmith to change the lock. Physical key is anonymous. Only you know which key unlocks which lock. If a random person finds your physical key on the street, they shouldn't be able to find their way to your lock to try and unlock it. 2. That's all well and good. Now, comes a magic key. That's your personal magic key. Any lock you are permitted to unlock, your magic key can unlock it. Any key you are not permitted to unlock, your magic key cannot unlock. Now, you can more than one magic key – where only some of the locks you are allowed to unlock can be unlocked by one magic key vs another. And if you happen to lose your magic key, you can call your locksmith to cancel your magic key – actually, that's a keysmith than a locksmith! 3. Your magic key is still anonymous. Only you know which magic key can open which locks. A random person who finds your magic key shouldn't be able to find their way to all the locks it can unlock. 4. When you see a lock, you are prompted to insert a key. The prompt doesn't say which key. You try one of the magic keys have that you think should unlock it. If it happens to the wrong key, not a big deal. You just try another magic key you have, and if that's the correct key it will unlock it. 5. When you buy a new lock (sign-up), you decide which magic key you have that should be the one to unlock it. This pairing of the key to the lock is done simply by asking pair a key to the lock. You are not being told to use a specific vendor of magic keys. You are not being peddled only magic key vendor over another! 6. If you want to change the magic key paired to a lock, you can do so at anytime on your own as long as you are in possession of the current magic key. 7. And of course, you can have multiple magic keys paired to the lock, so that you can unlock with any of the keys. 8. When you use a key to unlock a lock, the lock can tell which paired key was used – you can give nicknames to the paired keys that the lock remembers. The lock will tell you which nicknamed keys were used to unlock it previously and when. ----- Here's where I think passkeys went awry. They became yet another platform war. The OSes and browsers are supposed to be neutral and provide an unobtrusive prompt for user to pair a key or use a key, that's it. And the user should invoke a keyring against that prompt. If the keyring provider has features – like portability or non-portability of keys etc that's unique to each key ring provider and as long as the user is comfortable with it, everyone should be good with it. The prompt needs to be unassuming. Today it is very assuming and that's the problem!
• jmakov 2y ago
  How is this different than just using your SSH key?
  • mixmastamyk 2y ago
    One difference is that it is hardcoded to the destination site.
• tasuki 2y ago
  > chosen to sync the passkey using my 1Password password manager. In theory, that choice allows me to automatically use this passkey anywhere I have access to my 1Password account I have never used passkeys and don't know much about them, but isn't the main point that they're distinct per device? If one syncs pass keys using a password manager, what benefit do they bring over passwords?
  • Groxx 2y ago
    The main benefit: if used to replace passwords, they eliminate bad passwords and password reuse and password leaks by things you log into. Which is a gigantic improvement in practice, as those are extremely common ways for mass account theft. (I am not personally a fan of passkeys for a variety of reasons, but the main goal is very pragmatic and something like passkeys is a very obvious choice. I just don't like this spec, the UX awfulness and railroad-everyone-into-giga-corp-systems-and-giving-up-all-control shown in this article is a direct and very predictable result of the spec's decisions.) --- Per-device is an option (part of the spec, and I believe always allowed), but it has a bootstrapping problem that leads to custom out-of-spec shenanigans (how do you attach your account to a second device, without any other way to log in, if the new device has nothing that can prove it's related to the other?) and most people don't have enough devices to be able to have guaranteed backups. Lose your phone and you might lose literally everything. Or a house fire. Data is FAR easier and cheaper to put in multiple locations for redundancy. Also I set up new devices like a dozen times a year, whether it's a new physical device (relatively rare) or simply an erase and start over / OS switch (at least annually , it ensures my backups work and I get rid of cruft). If my passwords weren't backed up and handled with far more paranoia than my browser session, I've have lost them at least a couple times.
  • Arnavion 2y ago
    They don't bring any user-visible benefit over passwords if you use a password manager for your password (so that the password is stored securely on disk behind the password manager's login) *and* the password is unique and large (eg randomly-generated by the password manager) *and* you have the password manager autofill it instead of copy-pasting it manually (because the password manager can reliably check the domain name without falling for lookalikes, homoglyphs, etc). From a UX perspective, passkeys eliminate user choice about the above matters, so it's easier to railroad users into secure-by-default. From a technical perspective, a shared secret like a password is generally worse than an asymmetric key like a passkey, especially since stupid websites can save the password directly instead of using a KDF in the usual way and then get breached, but if the secret is unique that matters less.
• gwbas1c 2y ago
  The best way to solve a big problem is to break it up into lots of tiny problems. It seems like, IMO, the best way to get the general public to adopt passkeys, and to refine (cough debug cough) the UI, is to use them in low-stakes situations, in a gradual rollout. Instead of focusing on high-stakes use cases, like banking, perhaps: 1: Focus on low-stakes situations, like blogs and news sites 2: Services need easy ways to "add a device," such as opening a link in an email or SMS on the device they want to use. 3: Don't bother syncing passkeys across "devices." Instead, focus on syncing within the browser, where passkeys sync however bookmarks sync. 4: Work on APIs for a user to elect to use a 3rd party passkey manager At that point, services like iCloud, OneDrive, Google Drive, ect, could also provide passkey synchronization. It's up to elect to use such services; because otherwise, re-signing-in on each device the user uses might be "good enough."
• tonymet 2y ago
  Every additional factor just weakens the chain. None of these solutions addresses the social attacks due to decreased usability. Users are more confused and have less control now. They will spam every factor to get to their resources.
• notatoad 2y ago
  regular people strongly disagree. from what i can tell, people who aren't HN commentators or tech bloggers love passkeys. you click "sign in" and you are signed in. that's the dream. my non-technical family and friends have been lamenting not being able to do that for years. my customers are asking for it.
  • hbn 2y ago
    Give it a few more years to marinate, and people start getting new devices. Then we'll see how good this actually works.
  • gavinhoward 2y ago
    And that will quickly reverse once people start losing their accounts by losing passkeys or devices. My extended family fought me about migrating to Signal for years. I stopped trying. One or two years later, they were all on it, acting as if they hadn't given me grief for it. They have learned their lesson, though. A couple of them have come to me asking about passkeys, and I tell them the threat of losing access and let them make their decision. I think both of them chose to keep passwords.
    • Groxx 2y ago
      Every person I've talked to in person who has used passkeys has lost all their passkeys at least once, by no fault of their own. The more techno-masochistic ones tried again immediately out of curiosity (hence "at least"), but the rest have sworn off passkeys permanently. And I don't blame them. Without cross-platform sync being standard and literally everywhere, it's trusting hardware and OS vendors to do a good job and inter-operate correctly for the long-term future. They've all used computers for long enough to know that's not something you can trust them with, particularly not in low-margin devices like most people use.
    • notatoad 2y ago
      i think you're overestimating how good people are about maintaing their passwords. if you tell people "you'll lose your passkey and have to reset it" they'll freak out. but most people lose their passwords and get locked out of their account on a somewhat regular basis anyways. people suck at passwords. if they can have that level of reliability with a bit more everyday convenience, they'll be happy.
• benced 2y ago
  I'm really not convinced by passkeys as a socio-technical phenomenon because it seems to lock people to their OS. As a technical user, having them in 1Password which is OS-neutral (and plans to support export eventually - I'll change my mind on passkeys if this never comes), they're great.
• rawgabbit 2y ago
  I guess I am a bit dense when I create Apple passkeys for the few websites that support it, I don’t have any issues with using chrome or safari and macOS or windows? I will test again but I don’t remember experiencing this.
  • lll-o-lll 2y ago
    I think there is a big difference in experiences for people who are in the Apple ecosystem and people who aren’t. Apple has made the whole show seamless, so you move from device to device and everything just works, your passkeys are there. At worst, you use your phone to do the login. It’s also seamless if you lose a device. Your new device has your passkeys, and you can get by with an iPad or older phone until replaced. I think the space where people have all the pain is outside of this ecosystem. Apple is showing it can be done well, but it’s clearly not the experience people are having outside of that walled garden.
• cratermoon 2y ago
  "Most try to funnel you into a vendor's sync passkey option" Therein lies the problem. Every vendor's profit motive and #enshittification means they want to own your passkey and all the personal data associated with it. None of the care to interop or work with decentralized solutions. They need your data, and they'll do everything they can to lock you into their jail.
• dp-hackernews 2y ago
  Why not use something similar to SQRL instead? https://en.m.wikipedia.org/wiki/SQRL https://en.m.wikipedia.org/wiki/SQRL
  • commandersaki 2y ago
    This is from the guy that created a new, unnecessary, cryptographic primitive by chaining multiple invocations of scrypt instead of modifying the parameters/rounds of scrypt.
• paultopia 2y ago
  This matches my experience perfectly. As someone who is technically skilled but has no particular security expertise, I've tried to gradually implement passkeys where available across the most important and frequently used of my accounts, and... I'd have to go read the goddamn spec to have any idea what's going on. Pretty much all I've learned is that sometimes I can use touch ID to log into stuff now, and sometimes I can't, and the reasons are totally damn opaque.
• greatgib 2y ago
  The magic of password is that you can write them to paper or keep them in your mind. No interoperability issue if suddenly having to use it temporarily or permanently with another device, like if you lose your phone. And you can also pretend they don't exist and no one can prove otherwise. Also if you don't use a password manager, no one (hacker or else) can extract it from your head like it can be forced from your devices.
  • jeroenhd 2y ago
    That password is Hello123! for most people and that's why people get “hacked”. Great that you're one of the dozen or so people who can keep hundreds of passwords in your memory palace for several decades, but that's not feasible for us mortals. Good passwords are hard because password booklets get lost, or aren't nearby when accounts are created, and people are terrible at remembering hundreds of passwords. Or even ten passwords, as I've found out working helpdesk. If everyone used passwords safely, we wouldn't need 2FA on all that many services. Unfortunately, credential stuffing remains super effective. I'm not saying passkeys are the perfect solution here, but pretending passwords are fine as-is is just burying your head into the sand.
  • Calamityjanitor 2y ago
    Realistically passwords can also be forced from your head using 'enhanced interrogation techniques'.
• gsibble 2y ago
  I agree with many of the downsides but the only devices I use are Apple. Macs, iPhone, iPad. For me, passkeys are universally simple. Sorry other OSes and browsers other than Safari, which I switched to specifically for passkeys and Apple Pay, aren't as elegant. That's Apple's advantage. Their hardware and software ecosystem. And that's why I never look at anything else.
• godelski 2y ago
  I recently switched from Android to iPhone (and had to get a second iPhone because in <2 weeks I got more scratches on my screen than I have on my multiple droid devices used for 5 years...). I learned a lot about 2FA from that experience... not in a fun way. The problem really comes down to this: let me register >1 devices for authentication! Luckily Google does this but many places don't. So you're kinda fucked if you exchange your device and don't convert everything first. Interfaces are crazy bad. Firefox is a good example: go to manage account, scroll down to "Two-step authentication" and you'll see "Enabled" with an option to "Disable" or "Get new codes". But I registered this into Ente! Even FIDO keys say you should buy tap two. One to lock in a safe (they should make this easier by allowing some way to clone a key). Why can't I register 2 devices or multiple methods. More so, why can't I set some priority leveling like prefer security key, email if OTP is used, require message to fall back to email OTP. This isn't just a problem with passkeys, this is a security problem in general. I really don't think there's enough thought put into how things happen in the real world. I'm pretty techy so got my issues solved but if it were my parents? Well they would swear at me for having implemented that security and never trust me again, falling back to much lower security. It's hard to blame them. So does anyone know the real way to solve these issues? We're on Hacker News. Yes, the best security is if you lose a key you lose access, but this doesn't work for the real world and for most people. You shouldn't be at risk of losing an account if you lose or destroy your phone. We should also have solutions that don't require internet or reliance on big tech 3rd parties that get Metadata as is the case with single signons. Yes, provide that option, but there's got to be a better way (that can also permeate into standard practices!!!)
• __MatrixMan__ 2y ago
  I'll be avoiding them until I'm sure that the attestation object is not being used as a nefarious back channel between the vendor of my authenticating device and the service that wants to authenticate. The way the protocol is set up now feels like a slippery slope towards a world where I can't be sure that my new accounts aren't actually containing information about whether I had been to a protest recently or whether, at the time of sign-up, my biometrics indicated that I was in an altered state and likely to be easier to fool than usual.
• dilippkumar 2y ago
  I wasted an inordinate amount of time trying to fight Apple Vision Pro to get it to read my Yubikey. I failed. My apple vision pro was rendered useless because of a single passkey. Dumbest tech ever.
• franga2000 2y ago
  Passkeys are simply over-engineered. A passwordless login system need only the following: - $AUTHENTICATOR is one of (browser extension, browser, OS, hardware) - $AUTHENTICATOR stores mappings ($SITE,$PUBKEY) => $PRIVKEY - $SITE can ask $AUTHENTICATOR to generate a new $PRIVKEY and give it its $PUBKEY - $SITE can ask $AUTHENTICATOR to sign a challenge with the $PRIVKEY corresponding to one of the $PUBKEYs for that $SITE - the user can pick which $PRIVKEYs are synced and which can be exported (depending on $AUTHENTICATOR capabilities) Bonus points for adding a way to do the authentication off-device through QR codes, so $AUTHENTICATOR one one device can authenticate a session on another device (like using a phone to log into $SITE on the desktop, perhaps for the purpose of adding another authenticator there).
  • commandersaki 2y ago
    Fully agree. I'd say the overengineering is to support competing vendor interests and introducing crap like attestations. Though, I believe some extra engineering is needed for the constrained resources on a hardware token authenticator.
• mystified5016 2y ago
  I'm so unimpressed with passkeys. It's just like blockchain, trying to solve a poorly defined social and legal problem with pie in the sky 'elegance' and overly complex technological solutions. I don't think cryptography is the way to solve phishing. I mean sure it can, clearly. Bitcoin also works as a currency, but it hasn't stopped people scamming and stealing money. If you're a person wondering if you need passkeys: you need a password manager instead. If you learn some basic safety habits and always trust your password manager, you get almost all the benefits of passkeys with almost none of the downsides. Passwords— if used responsibly— are fine for 99.9% of what anyone wants or needs. To be responsible with passwords, you just let the computer do it. That's really the problem passkeys solve, just in the most typically obnoxious way.
• IYasha 2y ago
  How about every site and service let me use my username+password combination and stop bothering me with 2-3-4-5FA bullshit? I can manage my own passwords, thank you!