Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passkeys: The beginning of the end of the password

blog.google

Post reply on HN
Print view View original

461–470 of 1001 posts

Re: Passkeys: The beginning of the end of the password

#461

Post by bscphil »

chlorion wrote: post #453
mastazi wrote: post #386

Earlier quoted context omitted.

So it's like a private key but you can't access or manage it, as it's owned by Google/Apple/Microsoft? How convenient!

Passkey is an open standard, clients are not limited to Android or IOS devices. You can for example use a Yubikey, on a Linux desktop system, to authenticate to services implementing the "passkey" standard. Does Google own my Yubikey in some way that I'm unaware of? Nothing is owned by Google or Apple or Microsoft, there is no grand conspiracy trying to lock you into a platform. Try educating yourself before spreadin…

Possibly a dumb question... the Yubikeys a bunch of us own were originally sold as U2F / FIDO keys. My understanding of this system was that it was, as labeled, a "universal second factor" standard. But passkey is supposed (?) to be a single-factor (something you have, not something you know). Is it doing this just by (ab)using the "second factor" approach for single factor auth? Or is there something a little more sophisticated, and hopefully more secure, happening here?

I tried to do some research myself, but there's no Wikipedia page for "passkeys" and they aren't mentioned on the Yubikey article.

Edit: this user has a helpful comment: https://news.ycombinator.com/item?id=35810144

> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.

I'd love to know more about how / whether these challenges are enforced as part of an open standard, or whether it's up to individual implementers of passkeys to roll their own.

Re: Passkeys: The beginning of the end of the password

#462

Post by bscphil »

Shank wrote: post #391
ouraf wrote: post #385

Earlier quoted context omitted.

Well, guess it won't work for me. Rooted phone and prone to boot loops and hard resets whenever i get curious with some stuff. Every authenticator stored in the phone can't be recovered when you install a new ROM (google tries to send the authorization pop up to the previous version of the phone and, of course, it'll never get there) Guess that's the price i pay for using the hardware in a slightly different way than…

> Rooted phone and prone to boot loops and hard resets > using the hardware in a slightly different way Honestly I wouldn’t classify turning a daily driver device into a semi-brick (if it boot loops and has to be hard reset regularly…) as “slightly different”. If you want to experiment that’s fine, but why would you subject your daily driver to that? Or, why not just have a phone for stable use / real world stuff, an…

> To put it bluntly: you’re wildly out of touch with reality for most people. 99% of people who have a phone

I don't think 99% of people who have a phone have any kind of extensively worked out plan for what happens if their phone is lost, stolen, or breaks. If we're lucky the number is more like 50%. For most intents and purposes, irrevocably losing access to a phone is equivalent to bricking it in the way OP talks about. Any passkey-esque system needs to have a fallback plan when the phone unexpectedly becomes unavailable.

Re: Passkeys: The beginning of the end of the password

#463

Post by bscphil »

dwaite wrote: post #438
scott00 wrote: post #420

Earlier quoted context omitted.

The passkey itself is an encryption key. When you register a passkey to access a site, the component that holds the passkey generates a site-specific asymmetric encryption keypair. It then gives the site the (unencrypted) public key, and the private key encrypted with the passkey. To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private k…

> The passkey itself is an encryption key. Close - it is a signing key, e.g. used for integrity and authentication > To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in. This…

> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.

Thanks for this helpful comment, it helped me understand the difference between U2F and passkeys. I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected. (I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys, or would this necessitate buying a new device - if you're not willing to use your phone for the purpose.)

Re: Passkeys: The beginning of the end of the password

#464

Post by yarg »

jimmar wrote: post #294

The paragraph in the section, "What are passkeys?" tells me that they: are new, are easier, let me use biometrics, and are resistant to attacks. But, it doesn't tell me what passkeys actually are. Compare passkeys to traditional authentication factors. What's a password? A secret word or phrase that only you know. What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or re…

> What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or retina.

The key word being identify, as opposed to authenticate.

Authentication using biometrics is only secure as long as the object being scanned cannot be physically replicated and you can verify that the data source is a physical scanner and not a simulation of one.

How do you implement that without compromising device repairability?

Re: Passkeys: The beginning of the end of the password

#466

Post by dwaite »

bscphil wrote: post #463
dwaite wrote: post #438

Earlier quoted context omitted.

> The passkey itself is an encryption key. Close - it is a signing key, e.g. used for integrity and authentication > To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in. This…

> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry. Thanks for this helpful comment, it helped me understand the difference between U2F and passkeys. I'm wondering whether these challenges (biometric / knowledge) are…

> I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected.

The WebAuthn spec describes a Javascript API, and CTAP describes how to communicate with authenticators over various transports (USB and NFC being the ones with the most implementations).

Actual conformance to these, requirements on behavior, and things like whether the hardware has mechanisms to protect certain types of attack if someone has physical access all fall into certification. The implementations can provide attestations, which allow a third party like FIDO Alliance to assert some level of certification (even if at lower levels the implementation details are self-asserted by the implementer).

Without certification, it is the manufacturer's word to the user that it has proper security and protections. Without attestations, there is no guarantee to the site requesting authentication that any particular process took place or that the credential has any particular form of security.

But the reality is that while we have built sophisticated _models_ for describing authentication and compromise risks, most consumer-facing infrastructure is a hodge hodge of password-backed accounts with email recovery.

The user already has full choice in how they manage passwords - from established to shady software makers, to a printout of an excel spreadsheet in 5 point font they keep in their back pocket. The SMS you sent out to verify the user's account may very well be protected by a carrier account with the same password the user supplied to you at registration.

> I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys

Passkeys are "just" WebAuthn credentials with a couple of features - e.g. discoverability and user verification. With usability caveats (say, limitations around UX with NFC key fobs) I would expect hardware from the last 2-3 years to support passkeys just fine.

Support for new features may be added over time, both in software and hardware. For instance, a 2020 security key fob might only support a dozen passkeys, while a more modern fob might be able to store hundreds.

Re: Passkeys: The beginning of the end of the password

#468

Post by nine_k »

mrb wrote: post #323
Dalewyn wrote: post #312

Earlier quoted context omitted.

Passwords will never be supplanted unless the new challenger can satisfy all of the following: * Easy to understand. (A password is just a word/phrase/string of characters only you know.) * Easy to use. (Using a password only requires remembering and typing it in when prompted.) * Convenient. (Only your ability to remember and type required. No other tools or gadgets required.) * Simple. (All of the above.) If someth…

Passwords will never be supplanted? As always, it's a false dichotomy. Passwords will continue to be useful for some scenarios, but in others they will and are being replaced by other methods such as biometrics, U2F tokens, etc

Biometrics should never serve as a password. It may serve as a login.

Passwords should be easy to retire and change if they are compromised. You can' easily change your fingerprint or iris circle on demand, if somebody makes a good enough copy.

Re: Passkeys: The beginning of the end of the password

#469

Post by nine_k »

grupthink wrote: post #400
berkle4455 wrote: post #310

Earlier quoted context omitted.

It’s a password that Google controls so when they incorrectly ban you from their services you lose access to literally everything. Or if you drop your phone in a lake you’re out of luck too.

Banning has nothing to do with it. You use passkeys as a preferred login method. If you do not have your passkey, you can tap "Try Another Way" and use your password as usual.

This means that you still need a password, which you still should store securely.

It just becomes much harder to phish out this password.

Re: Passkeys: The beginning of the end of the password

#470

Post by diego_sandoval »

So, what I take from this announcement and the linked article [1], is that:

This is a closed system, with no public standard protocol, where you will have to use the stock closed-source operating system that comes with your phone, and you will need to have your cellphone with you every time you need to login, even if you want to login on a different device, and presumably, that phone also needs to have an Internet connection.

Maybe I misunderstood something, but I would never voluntarily use such an abomination.

[1] https://blog.google/technology/safety-security/one-step-clos...

Post reply on HN