• Off Topic
  • what is your opinion on the "new" passkey release of google?

I just read that google released this feature called passkey which supposedly is safer and easier to use instead of an password manager. Is it safer though? Or just another way of google to keep you fully into their ecosystem? What's your opinion?

    Passkeys are very new, but I'm personally very excited about the prospect and hope they get widely adopted so that people can use them for their accounts.

    While things are pretty closed between a few passwords offering the option like Google, Apple and Microsoft, that will increasingly stop being the case. Major password managers like Bitwarden and 1Password have already fully committed to adding support for them, so you won't be "locked" into Google's or anyone's ecosystem when using them, which is good.

    I like that TOTP and hardware security keys are an open protocol; I don't need to rely on some corporation to generate and manage my secrets for me. With TOTP, they give me the secret key, and I can generate a TOTP code with any program, without an internet connection. I don't even need a phone to do it. I can use a program on my computer. Hardware security keys are similar with the FIDO2 U2F standard.

    While I've made an attempt to understand passkeys, I must confess I'm completely unsure about how they work even after reading an article or two about them. If they require remote attestation, that would be far more brittle and give the user less control than TOTP or hardware security keys.

    After some research:

    I see passkeys are meant to replace passwords; not be used as a second factor. This is obviously less secure than properly implemented password + second factor, but some services do not implement second factors properly, so this might end up being more secure because it enforces a strong password. In that case, I think hardware security keys should be treated as offering the same level of security and be allowed to be used in place of a password with more services.

    https://developer.apple.com/passkeys/ - Apple syncs passkeys with the iCloud Keychain. If you aren't aware, you can't transfer the keychain to an Android or non-Apple device. It isn't clear whether you can extract keys from it easily, or at all. It also doesn't say whether it works offline. Also, this page doesn't explain how passkeys work at all.

    https://developers.yubico.com/Passkeys/How_passkeys_work.html - Some observations:

    • I'm not a fan of the terms 'registration ceremony' and 'authentication ceremony'. Authentication is not something to be celebrated. It should be treated professionally and seriously.
    • Still not much detail...
    • Some more detail on other pages but far too dense and not giving me any of the answers I'm looking for.

    So why not try the standards page by FIDO? https://fidoalliance.org/passkeys/

    FAQ
    What is a Passkey?
    ...
    Passkeys that are managed by phone or computer operating systems are automatically synced between the user’s devices via a cloud service. The cloud service also stores an encrypted copy of the FIDO credential. Passkeys can also by design be available only from a single device from which they cannot be copied.

    Getting closer...

    Since phone based passkeys sync across all of a user’s devices, the process of upgrading to a new mobile phone is a seamless transition.

    I'm pretty sure Apple's implementation is not done this way, but I'm happy to be corrected.

    Yes. There is no change to the local biometric processing that the user devices (mobile phones, computers, security keys) do today. Biometric information and processing continues to stay on the device and is never sent to any remote server — the server only sees an assurance that the biometric check was successful.

    Okay, so no remote attestation? Or remote attestation, but not through biometric data? Hmm...

    The FIDO alliance thinks OTP codes are insecure:

    But unfortunately the most popular forms of second factors — such as one time passwords (OTPs) and phone approvals — are both inconvenient and insecure. They can be phished, and they are being phished at scale today.

    I don't think passkeys are immune to fatigue attacks, either. Are passkeys not also approval-based..?

    Device OS platforms are implementing a feature by which the passkeys on the device (for example, a mobile phone or laptop computer) are synced to the device cloud tied to the user’s platform account (eg, Apple ID for iOS/macOS, Google account for Android & ChromeOS, Microsoft account for Windows). Syncing of passkeys is end-to-end encrypted.

    When a user creates a passkey on any of their devices, it gets synced to all the user’s other devices running the same OS platform which are also signed into the same user’s platform account. Thus passkeys created on one device become available on all devices.

    It looks like they try to get around device syncing by saying it's okay if you have your other device nearby:

    The user visits the RP website on the Windows computer. They then see a ‘sign-in’ button on the RP’s login web page and push that button. The user now sees the option to use another device to sign-in to the RP.
    So it sounds like passkeys are bound to each 'ecosystem'. As long as you use all Google devices, all Apple devices, or all Microsoft devices, you can sync your passkeys around. If you mix-and-match, expect trouble.

    Oh, they explain how to switch from one ecosystem to another; it seems mutually exclusive. You can either have an Android device with a passkey, or an iOS device with a passkey:

    If the user is still in possession of their old device, the user can use the passkey on the old device (say, an Android device) to sign the user into their account on the new device (say, an iOS device). Once signed in, the user can create a passkey in the new platform account.

    Okay, that sounds really annoying. Hardware security keys are already sounding far better. I don't have to get up, go across the room to get my phone, unlock it, approve the passkey notification, and go back to my computer. I can just pickup my security key and plug it in, then tap it.

    So after all that, I still don't know if passkeys require remote attestation. Also, it sounds like they don't trust you at all with the Secret, which is why you need to create a new passkey when you move between 'ecosystems'. This is the same reason you shouldn't use Authy because it doesn't give you the Secrets. It doesn't let you back it up in case you really need access one day.

    Passkeys sound like an absolute pain for people who aren't heavily invested in one of these ecosystems, don't use a phone all the time, and are interested in transparent access to their secrets. i.e. Me.

    Happy to be proven wrong. Keep in mind this is just a result of all the research I've done in appropriate places, so I'd appreciate if the responsible parties explained things better if I'm getting things wrong.

      Okay, okay, one more post and I'm done. I missed the last FAQ question:

      Yes, FIDO Security Keys today support single-device passkeys and have done so since 2019, when FIDO2 added support for passwordless sign-ins via discoverable credentials with user verification. All the client platforms and browsers have native support to exercise security keys already. Security key vendors may choose to support passkey synchronization in the future.

      Hardware security keys also support passkeys. I fail to see the point of this, but it's a thing they can do. Hardware security keys already support FIDO2 U2F Webauthn, which is a similarly 'unphishable' standard. There is no benefit to using a hardware security key with passkeys. It seems like they're only useful in circumstances where you're already using passkeys without a hardware security key:

      Also, in scenarios where a user has lost access to all of their other mobile and other devices where their passkeys have been synced, such FIDO Security Keys can act as a recovery credential.

      And there's this, which I don't understand at all. It's not like you can have more than one physical key...right?

      Specific environments with particular compliance needs may be required to guarantee there is only one copy of the cryptographic key available. Passkeys on FIDO Security Keys are a great solution for such use cases.

        Equal2024 Like you, I spent some time trying to understand passkeys a while ago. It's important to understand that passkeys are not passwords at all. Perhaps the "passkey" name creates confusion on this account. As far as I understand, they use public-key cryptography, the same as something like PGP or any proper end-to-end encryption protocol.

        So the account you're logging into knows your public key and you hold the private key. Only the device holding the private key can autheticate the account and nothing is transmitted that can be comprised (only the public key is transmitted). This means passkeys are not subject to phishing attacks, they are resilient against man in the middle attacks, and can't be stolen from servers, like passwords. Again, that's all as far as I understand.

        So passkeys resolve a lot (most?) of the ways that people are subject to attacks online and are far more secure than passwords, including passwords in combination with two factor authentication (which can and has been man in the middled).

        The weak link is the physical device, usually your phone, that stores the private keys and you need to have in your possession to get into your accounts. If someone has access to your phone and unlocks it, because you have a easy to hack pin or biometrics that aren't as hard to defeat as people think, then they have access to your accounts.

        However the reality is, mostly people are getting compromised by online attacks, not physical attacks, so overall there should be a lot less problems with something like a passkey.

        One thing that's super confusing about the way passkeys have been promoted is the claim that they represent the end of passwords. That's true on the back end. The mode of authentication bettween client and server no longer uses passwords, it uses public-key cryptography which is fundamentally different and just is not a password in any way shape or form. But the end user will still have to unlock their phone or a password manager, to allow it to autheticate your login to a website and that is still a lot like using passwords.

        Also, what do you do if you want to login to an account, on someone else's computer, and you don't have your phone? You now do not have your private keys, so I guess it's impossible to login? That's actually much less convenient than a password, whatever its downsides are. It's all kind of predicated on the idea that people have their phones with them all the time.

        In the end, I think it will, if it's widely adopted, solve a lot of problems with people's accounts getting hacked. But whether the end user will find it to be so great, I don't know.

        Here's a not be explanation of many of the aspects of passkeys: https://www.csoonline.com/article/3685933/how-passkeys-are-changing-authentication.html

          cb474

          As far as I understand, they use public-key cryptography, the same as something like PGP or any proper end-to-end encryption protocol.

          So basically, they're SSH keys? Except most current implementations don't give you access to the unencrypted private key, from what I understand.

          I must admit I plugged the FIDO Alliance article into Kagi's Discuss Document tool after writing these three posts, and it affirmed what you've written. You can blame my lack of reading comprehension or the FIDO Alliance's obtuse method of communication, but either way, your explanation is much better.

          One thing Kagi's tool emphasized was passkeys not using shared secrets like TOTP. I think that's a great improvement; public-private keys is a much more breach-resistant method of authentication. As you point out, even if the server is breached, they will only get the public key, not the private key. This also completely defeats credential stuffing attacks. A game-changing improvement over current methods of authentication for most people.

          However...hardware security keys supporting FIDO2 U2F offer the exact same benefit and they have wider adoption currently and are more convenient (in my humble opinion). Of course, it won't stay that way. Very few users are going to buy a hardware security key, but modern society demands you have an Android/iOS phone today.

          The weak link is the physical device, usually your phone, that stores the private keys and you need to have in your possession to get into your accounts. If someone has access to your phone and unlocks it, because you have a easy to hack pin or biometrics that aren't as hard to defeat as people think, then they have access to your accounts.

          Same thing as password managers, which most people should be using. Most people protect their password managers behind biometrics, too, and their 2FA app is usually completely unprotected. This is no worse for most people. As you mentioned, physical attacks are rare anyway.

          One thing that's super confusing about the way passkeys have been promoted is the claim that they represent the end of passwords. That's true on the back end. The mode of authentication bettween client and server no longer uses passwords, it uses public-key cryptography which is fundamentally different and just is not a password in any way shape or form. But the end user will still have to unlock their phone or a password manager, to allow it to autheticate your login to a website and that is still a lot like using passwords.

          The fact that a lot of coverage focuses on how to use passkeys (using your biometrics to unlock them) and not on how they work exacerbates this confusion.

          Also, what do you do if you want to login to an account, on someone else's computer, and you don't have your phone? You now do not have your private keys, so I guess it's impossible to login? That's actually much less convenient than a password, whatever its downsides are. It's all kind of predicated on the idea that people have their phones with them all the time.

          I very much agree with this notion, but also have to concede that most people do have their phones with them all the time. The more realistic risk is their phone runs out of battery. But as mentioned previously, Bitwarden and other password managers plan to adopt passkeys. Keepass might do this too. In my opinion, password managers offer the only passkey implementation that should be adopted. Bitwarden can be used anywhere, including the web. You aren't locked into any 'ecosystem'.

          I don't remember most of my passwords either, depending on my password manager for that, so the situation is no worse for me. Unfortunately, the only convenient method of logging in on another person's computer is probably going to be carrying your phone around in both scenarios. Or remembering your 40-character randomly generated password. Or if it's an account you see yourself doing that with, not using passkeys.

          Edit: Another scenario where the passkey implementation is weaker than traditional passwords is you unlocking your phone in public, then having it stolen. In this scenario, the password manager implementation of passkeys is much better. If you protect your passwords with your 128-bit entropy master password and not biometrics, you're good.

          Thank you very much for that explanation. I know I would have struggled for some time to understand the passkey standard properly without it.

          So, all in all, my opinion is:

          • Passkey standard = good
          • Most passkey implementations = bad because they only work within an 'ecosystem'. Most implementations are also proprietary.
          • Most people will use the bad passkey implementations unless they know better. Most people will not know better until they experience first-hand why the passkey implementations are bad. Like when I realized Google Authenticator was a bad 2FA implementation because it doesn't give you the secrets, and then had to re-create 15 2FA secrets.

          Equal2024 I'm pretty sure Apple's implementation is not done this way, but I'm happy to be corrected.

          Pretty much, pass(word|keys) are stored and synced via iCloud keychain encrypted with the iPhone passcode with hardware security modules on Apple backend to stop bruteforce.

          Equal2024 Okay, so no remote attestation? Or remote attestation, but not through biometric data? Hmm...

          Remote attestation is an optional feature websites can request for higher security, biometric is just the way the local password manager lets you access passkeys. You can use whatever you want, face fingerprint, passcode, smile on camera, or none.

          Equal2024 The FIDO alliance thinks OTP codes are insecure:

          Subject to phishing.

          Equal2024 I don't think passkeys are immune to fatigue attacks, either. Are passkeys not also approval-based..?

          Yes, you approve login but since passkeys are phishing resistant, at most you are logging in to the real website or app

          Equal2024 You can either have an Android device with a passkey, or an iOS device with a passkey

          I don’t think there is a way to export Apple -> Google or viceversa, but you can have multiple passkeys for one account, so you could save one for each plarform

          Equal2024 Okay, that sounds really annoying. Hardware security keys are already sounding far better. I don't have to get up, go across the room to get my phone, unlock it, approve the passkey notification, and go back to my computer. I can just pickup my security key and plug it in, then tap it.

          Passkeys are not created for techie people that intentionally buy multiple security keys, remember which is tied to which account, have with them when they need to login, never break or lose one. Passkeys are for the general public using insecure password with weak or nonexistent 2FA on their account.

          cb474 So the account you're logging into knows your public key and you hold the private key. Only the device holding the private key can autheticate the account and nothing is transmitted that can be comprised (only the public key is transmitted). This means passkeys are not subject to phishing attacks

          That’s not what makes them resistant to phishing. Passkeys and security keys are origin bound, they only work on the website they were registered on.

          cb474 Also, what do you do if you want to login to an account, on someone else's computer, and you don't have your phone?

          Well, if don’t have the phone but can still login, then you can proooobably remember the password, but you really should use random, strong, unique passwords stored in a password manager, for which you need a device for anyway.

            Titan_M2

            Pretty much, pass(word|keys) are stored and synced via iCloud keychain encrypted with the iPhone passcode with hardware security modules on Apple backend to stop bruteforce.

            My comment was related to the iCloud Keychain only able to be used on Apple devices. I would not call my iOS - > GrapheneOS experience a 'seamless transition'. The answer is written as if it only expects you to upgrade your phone to a different phone from the same vendor, when it is also possible you will be upgrading to a different phone from a different vendor. Later on, this is confirmed, but as you explain, it isn't as big an issue because multiple passkeys can be added for one account. You do still have to re-create all the passkeys, so it's still a pain.

            Also, they're still proprietary implementations. I still prefer the password manager implementation the most.

            Remote attestation is an optional feature websites can request for higher security, biometric is just the way the local password manager lets you access passkeys. You can use whatever you want, face fingerprint, passcode, smile on camera, or none.

            Thanks for clearing that up. The way it is written is ambiguous.

            Passkeys are not created for techie people that intentionally buy multiple security keys, remember which is tied to which account, have with them when they need to login, never break or lose one. Passkeys are for the general public using insecure password with weak or nonexistent 2FA on their account.

            I acknowledge the adoption issue in my other comment. I do have multiple security keys; one as a backup. I use the same keys for every account. I have never had any trouble with them. I even took them overseas without fuss. I don't think the general public would struggle to use security keys; I think the general public will never be convinced to buy them. I'm not saying they are made for everyone to use, but I want to acknowledge the technological superiority of hardware security keys. Namely; none of them are tied to a particular ecosystem and can be used on any device. I'll touch on the convenience factor later on.

            I recently saw a news report in my country that covered a company trying to sell pagers to banks and attempting to convince their customers to carry around pagers using a proprietary authentication method that cost twice as much as security keys. The horrible humor in this is they will probably succeed, despite the fact that I know my bank uses Yubikeys for their computers. In fact, I know of a country that has implemented something similar, except for everything - visit the MitID thread: https://discuss.grapheneos.org/d/1520-status-of-mitid-app

            I don’t think there is a way to export Apple -> Google or viceversa, but you can have multiple passkeys for one account, so you could save one for each plarform

            This solves one of two problems, which is the ecosystem lock-in problem, and by far the bigger issue. It does not solve the issue of accessing/backing up the decrypted secret key. I see the FIDO Alliance intends to get around this by entrusting the cloud service with a copy of your encrypted credential, which is fiiine...but I would really like them to be able to be backed up by the user.

            The user should always be in control. I realize anyone who knows anything about security will be the first to point out that the user is the most common cause of compromising their own security, but I don't accept that as a reason to take control away from the user, permanently. It's too easy an excuse for other bad behavior by vendors.

            Well, if don’t have the phone but can still login, then you can proooobably remember the password, but you really should use random, strong, unique passwords stored in a password manager, for which you need a device for anyway.

            And now I want to touch on the convenience factor of hardware keys. You can carry your hardware key around anywhere! Even, say...your friend's place. You could leave your phone at home, but as long as you bring that key and plug it into their USB-A slot, you can login to your account without your phone without a password. You don't have to worry about charging your hardware security key, either. I'm not planning on giving them up any time soon for passkeys. I will probably be forced to give them up anyway despite their superiority due to lack of adoption.

            I'm not saying that hardware security keys are something the general public will be able to handle not losing or is willing to buy. I will say that I've lost my phone twice in the past two years (for a short period of time), but in the five years I've owned my security keys, I haven't lost any of them. I'm not using this anecdote to prove anything except my life priorities, but nonetheless, sticking your keys on a lanyard around your neck will make them quite hard to lose. I've also never broken a security key, but on this subject, I will have to quietly agree with you that the general public cannot be trusted to take care of security keys.

            Thanks for your clarifications! I, for one, have found this thread very fruitful. I've changed my opinions at least twice, and I understand more about passkeys than I ever would have searching on my own.

            Good question, alexandros !

            ISTM it is BOTH; a safer means of "logging in" to a compatible site, AND another mechanism for Google to use to help build (and sell) its history of your online activities.
            I'm presently thinking I'll stick with a Keepass data base of very-complex passwords, copied to my various devices; and 2FA via my email account.

            BIG THANKS TO Equal2024 cb474 and Titan_M2 for helping to explain/understand this!!!

            P.S. Sigh...... I'm guessing that gmail users will soon be pressured to use passkeys at gmail and then elsewhere.

            Yikes! matchboxbananasynergy . I'm hoping that means that the present keepass functionality will add compatibility with the passkey architecture, and not be somehow replaced by it.

            cb474 So the account you're logging into knows your public key and you hold the private key. Only the device holding the private key can autheticate the account and nothing is transmitted that can be comprised (only the public key is transmitted). This means passkeys are not subject to phishing attacks.

            Titan_M2 That’s not what makes them resistant to phishing. Passkeys and security keys are origin bound, they only work on the website they were registered on.

            Can you explain more what the point is your making? I don't really understand.

            In a phishing attack, the attacker tries to trick someone into giving up their credetials (e.g. password) so they can use it to log into that person's account. But with passkeys the private key always stays on your device and it's encrypted, so you don't even know what it is, let alone have the ability to give it to someone else. So, I think my explanation of how passkeys resist phishing is correct.

            If it's not, again, I really don't even understand what you're saying and how it's different from what I said. So I'd appreciate a more detailed explanation.

              cb474 In a phishing attack, the attacker tries to trick someone into giving up their credetials (e.g. password) so they can use it to log into that person's account. But with passkeys the private key always stays on your device and it's encrypted, so you don't even know what it is, let alone have the ability to give it to someone else.

              It's actually more than that. Sophisticated phishing websites don't just read the password, but pose as entire frontend for the legitimate site. When you login into the phishing site, it authenticates on your behalf in real time to the legitimate site, this is how it can get through SMS, TOTP, Google prompt. If security keys and passkeys worked the same way, a phishing website could just as well trick you into logging in while on the backend they pass the authentication challenge to the legitimate site.

                Titan_M2 Sophisticated phishing websites don't just read the password, but pose as entire frontend for the legitimate site. When you login into the phishing site, it authenticates on your behalf in real time to the legitimate site, this is how it can get through SMS, TOTP, Google prompt. If security keys and passkeys worked the same way, a phishing website could just as well trick you into logging in while on the backend they pass the authentication challenge to the legitimate site.

                My understanding is that the newer FIDO protocols mix the client IP address into the challenge, so the response must originate from the correct machine and a stolen response won't work, unless the malicious person is running code on your machine.

                That is my hasty semi-understanding, though. If somebody corrects me, or goes into detail, we can all learn something.

                  de0u My understanding is that the newer FIDO protocols mix the client IP address into the challenge

                  That would be dumb, IP addresses do not uniquely identify users. Phishing resistance comes from the origin binding (emphasis mine): https://www.w3.org/TR/webauthn-1/#rp-id

                  A valid domain string that identifies the WebAuthn Relying Party on whose behalf a given registration or authentication ceremony is being performed. A public key credential can only be used for authentication with the same entity (as identified by RP ID) it was registered with.

                  Titan_M2 It's actually more than that. Sophisticated phishing websites don't just read the password, but pose as entire frontend for the legitimate site. When you login into the phishing site, it authenticates on your behalf in real time to the legitimate site, this is how it can get through SMS, TOTP, Google prompt. If security keys and passkeys worked the same way, a phishing website could just as well trick you into logging in while on the backend they pass the authentication challenge to the legitimate site.

                  Okay, I guess I would call that a man in the middle attack, not a phishing attack, so that's why I didn't understand how what you were saying applied to what I was talking about. I do feel less clear about how passkeys protect against man in the middle attacks. I'm still not sure I fully understand it, from what's been said in this thread.

                  Here's how Yubico describes the process for passkey authentication:

                  A passkey generation process creates a pair of mathematically related cryptographic keys: one private key that resides on the user’s hardware, and another public key that resides with the relying party, and linked to the account. During subsequent logins, the server will submit a randomly generated “challenge” to the user’s device, which it must respond to by signing said challenge using the private key. The relying party can then validate the authenticity of the private key by decrypting the response using the associated public key. If the original randomly generated challenge matches the decrypted response, authentication is confirmed and access is granted.
                  https://www.yubico.com/resources/glossary/what-is-a-passkey/

                  It makes sense how that prevents tradition phishing/social engineering, as I'm using the terms, but I don't really understand how that prevents a man in the middle attack. What's to prevent an intermediary website from capturing the challenge, passing it on to the end users, getting the signed response, and then using it to log into the website itself?