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

Titan_M2

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.

cb474

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?

alankeny

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.

cb474

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.

ustamills

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

Equal2024

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.

ustamills

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

[deleted]

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

[deleted] If I have your permission to lie a little I'll give it a try.

I believe the basic idea is that each web service you use (e.g., Twitter, Google) negotiates a very-long random password with one of your devices (e.g., your Pixel phone) to use when logging in to that web service. Then you don't need to remember a password for that web service, and they don't need to worry that you've picked a short password or a password you've used for every other web service. All you need to do is to carry your phone and remember how to unlock your phone, which you probably do naturally, and it's always great if a security scheme relies on what you naturally do instead of things that are annoying for you to do (like remember a different long password for each web service).

I lied when I said it's a password. It's not really the same thing as a password, so it can't be stolen while you're logging in to the web service, and if you are tricked into logging in to something that isn't the service you think it is, the passkey just won't work, so unlike a password it can't be phished.

I also lied when I said it's a separate password for each device, because some device ecosystems (e.g., Apple) have ways to synchronize a passkey across all of your devices. So if you want to log into Google Drive and your iPhone has a passkey for Google then your iPad will too.

If you already use a password manager with long random passwords, especially if your password manager does cloud synching between devices, then your setup is similar in many ways to what passkeys will do. Passkeys arguably are better because passkeys can't be phished, and also because lots and lots of people don't use per-site long random passwords, so passkeys might be a way to get a couple billion people to stop using "dog1234" as their password for 100 different web services.

Does that help?

Blastoidea

I found it totally confusing, and I have no clue if I set it up successfully or not.

Google needs to get a native speaker of Standard North American English to write a straightforward set of instructions, and accompanying explanation.

Obviously the geeks understand it, but it leaves the rest of us completely mystified.

[deleted]

I cherish the refreshing aroma of grass, nature and the woods, and I must say that I fully appreciate your wise concern over this crucial matter.

Personally, I am a great believer in the power of caution, especially when it comes to new technologies. Therefore, I would like to suggest like others have to, for you to take time and explore a range of password managers and security options, to find the one that best suits your individual requirements and values.

Furthermore, I would like to emphasize the importance of approaching technology mindfully and with an open heart and mind. Approaching it this way is the only way we can truly understand its full potential and avoid its potential dangers.

Namaste.

Blastoidea

I thought this was interesting.

https://security.stackexchange.com/questions/139712/how-secure-are-totp-codes

Relaks

Equal2024 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.

I'll jot down a few benefits, from the perspective of an organization/business:

Password-less (well, almost) sign-in to services and systems is a smoother experience from the perspective of employees. Especially if they are currently required to use separate, long and unique passwords for multiple services, SSO with a security key saves them the frustration of remembering multiple passwords. To mandate the usage of a security key in addition to passwords would add yet another dismay. It's already hard to convince people of the security benefit of security keys, and we don't want to implant in people more dissatisfaction towards IT security practices.
Phishing-resistance, as discussed in this thread
Removes the need for employees to carry a phone around with them for MFA. This is especially useful in institutions that fully prohibit phone usage, such as some prisons. Passwords + security key also solves this, but with added inconvenience.

Challenges:

Service support: many services have not implemented support for FIDO2 security keys. As an example, Google only added support for FIDO2 + PIN in Android last September. If services that an organization highly depends upon do not yet support FIDO2, a rollout might currently be severely impractical.
Cost. NFC readers are especially expensive, and would be necessary if one is to achieve user-friendly adoption (and to avoid a key becoming lost because someone forgot to unplug it from a computer).

I do not picture a world where most individuals carry around with them a security key for online services. A sync-based passkey implementation might be slightly less secure than a physical key in some aspects, but is security-wise far better than the currently widely adopted and highly phishable MFA methods, and generally more convenient.

I'm not against using security keys as MFA, and use it wherever I can. Especially since FIDO2 + PIN with a security key currently does not seem to work on GrapheneOS (currently unclear as to the cause of this).

« Previous Page