• Off Topic

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

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?

                                                    cb474 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?

                                                    See my quote above from the spec, the browser won't use the passkey to sign a challenge at all on a different website.

                                                        Titan_M2 See my quote above from the spec, the browser won't use the passkey to sign a challenge at all on a different website.

                                                        I saw the quote. It does not explain how the passkey system knows the wrong website is serving it the authenticaling challenge, it just asserts that it knows and that it won't work. I was just trying to understand how it actually works and why it's not subject to the sort of man in the middle attacks that are used with regular passwords and TOTP.

                                                        I'm also curious, if in the case of passkeys the browser can recognize that the wrong website is serving it the authentication challenge, why isn't that already used for security with plain old passwords? Why do man in the middle attacks work at all, where a website looks like the authenticate website, but is really a fake one, being used to capture passwords and TOTP, and then pass them on to the real site, so the fraudster can get into it? Why wouldn't the browser just recognize that the wrong website is asking for the password, etc., and reject it?

                                                          I'm not sure I'm the best person to answer this, but I'll give it a shot. My understanding is that passkeys generate a unique public/private key pair for each user, device, and website combination. The website's URL is stored as part of the passkey. The browser matches the passkey's URL to the website's URL used in its TLS certificate.

                                                          Traditional passwords and TOTP codes don't have a protocol to associate a password or code with a specific website. It's up to the user to know when to enter the right password or code on the right site. That's why phishing and MITM work so well, because the user can be tricked into entering a password or code on the wrong site.

                                                          Verification usually only works one way, because the server is the only side that has a public/private key pair for TLS. The client browser can verify the authenticity of the server, but the server can't verify the authenticity of the browser. The server just has to trust that the password or code is being sent from a valid client and not a MITM.

                                                          Technically most browsers do support client certificates, which a web server could use to verify a browser. In practice very few sites use client certificates, because they're difficult to setup and maintain on the clients. They tend to a require a centralized certificate authority that everyone has to agree to trust.

                                                          Passkeys get around this by generating a unique key pair for every user of every website, instead of a single client certificate that multiple sites need to agree to trust. Passkeys give up some centralized control, and they require more storage, but they should be easier to implement than client certificates combined with user passwords.

                                                            alankeny Thanks for the explanation. That does make sense. I can see how that would work.

                                                            One thing that's interesting about this is that it means passkeys really are doing more than just be alternatives to passwords. They don't simply verify that it's the correct person who is logging in. They also verify that the website is the correct website. So passkeys are a kind of two way, rather than one way authentication. Both parties are authenticated to each other. Of course, there are still other problems with passwords.

                                                            It also suggests that the two functionalities could be separate from each other. If there was a better way to authenticate the website you're logging into, then you could use a regular password and it would be more secure. As you point out, client certificates have not worked so well for this. But, in a sense, it's more this problem that passkeys set out to solve, than the problem of weak passwords.

                                                              Relaying a comment from another forum.

                                                              • Security keys can store passkeys, but you have to manage any desired redundancy and physical security.
                                                              • Phones can store passkeys but their weak protections (biometrics, patterns, etc) leave them vulnerable. Easy redundancy though.
                                                              • "If you don't have physical security, you don't have security."
                                                              • Passkeys are more resistant to attacks than passwords even with MFA.

                                                              All these seem to imply:

                                                              • For critical security use cases use a security key (with redundant copies secured), but protect its physical security carefully. Have a key cancellation process operational and handy in case you lose the key.
                                                              • For run-of-the-mill security your phone is good enough.

                                                              I will likely use redundant personally-managed security keys for finance, critical authentication, clients, etc. (Need a good lanyard!) I'll use my phone with passkeys for everything else.

                                                              Of course this is soon as I'm sure it's all working. 😁 I am not saying I've tested this yet. This just seemed like wise words to me.

                                                              Thought I would share

                                                              If someone could be convinced to give a phisher access to, say, their Google account, couldn't the phisher sync all of the victim's passkeys to their device, thus giving them quick and easy access to all of their passkey-protected accounts? Since we're talking about the average person, he likely would not tinker with the default settings, so would not choose single-use passkeys. Nor would the average person want to.

                                                              Compare this to convincing someone to give up the master password to their password manager—not likely. They may, however, be convinced to hand over one or two passwords to certain accounts. So I don't think it's accurate to say passkeys make phishing a thing of the past, and in the case of successful phishing, the compromise would have a larger impact.

                                                                Equal2024

                                                                Yeah, con artists are gonna con. Victims are gonna ... vic. I can't imagine either will ever stop.

                                                                "Three great forces rule the world: stupidity, fear and greed." - Albert Einstein

                                                                  14 days later

                                                                  Hi everyone, I've read articles and everything... I don't understand anything about passkey, I don't understand what it's for, if someone can explain it to me in children's words... I'd really like to understand. Thank you

                                                                  • de0u replied to this.