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

171–180 of 1001 posts

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

#171

Post by dcow »

lxgr wrote: post #153
segmondy wrote: post #41

I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/ . Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear o…

> use this to tether and lock you in to their platform. You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true. Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome insta…

You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just let me advertise some mDNS service record for "authenticator" and require me to advertise a pubkey and let the user select/allow me once and remember the decision until the pubkey changes so that I'm trusted backend without the QR scanning rigamarole.

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

#172

Post by lxgr »

sebk wrote: post #166
lxgr wrote: post #135

WebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards. At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures. I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requ…

For the client-side, the spec is comprehensive in allowing the authenticator to decide whether backups are allowed. In this case it's iOS not exposing that to you as a user. I get why you'd want this, but trusting Apple to store your single-device passkeys for high-stakes credentials but not trusting them for syncing them is somewhat of a very specific threat model I'd say, and definitely not in Apple's own interest…

> trusting Apple to store your single-device passkeys for high-stakes credentials but not trusting them for syncing them is somewhat of a very specific threat model I'd say

I don't think it's that specific of a threat model, to be honest.

Many people are logged into iCloud on multiple family devices – are they aware that with Passkeys, by default every device they are logged in to has single-factor access to their entire online life?

Additionally, Apple's iCloud security posture has been in the news lately with some quite horrible stories that are very relevant to Passkeys, in my view: https://www.wsj.com/articles/apple-iphone-security-theft-pas...

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

#173

Post by SadWebDeveloper »

This looks and feels like passwords with extra steps...

I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built.

What happens if i lost all my devices due to a fire? at least a password let me still access things we these i might need to prove again that i am me, it might even be more easy to steal accounts because i can ask google to change it because i lost my passkey.

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

#174

Post by petedoyle »

sebk wrote: post #123
petedoyle wrote: post #113

Earlier quoted context omitted.

This has been bothering me, a lot. Google talks [1] about how Passkey replication is e2e encrypted between devices, but AFAICT they're just using a pin + key derivation. A six digit pin is like 20 bits of entropy before a KDF. [2] Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)? I must be missing something, because I can't see how Google would call…

Talking about Apple here because it's what I'm more familiar with, and their security whitepapers are more widely available. The PIN and key derivation wraps the actual encryption key that's stored locally in the device or secure enclave, not the actual secrets that are stored in the provider's cloud. The actual wrapping keys are random 256 bit AES-GCM keys. This approach works because the secure enclave provides mea…

Thank you! I'm trying to understand more deeply, so I appreciate it. :)

> This approach works because the secure enclave provides measures against bruteforcing and tampering.

That's interesting!

> because that implies off-device use of the PIN, so those measures are lost

This link from your previous thread is interesting: https://support.apple.com/en-sg/guide/security/sec3e341e75d/...

Uses SRP to let the device prove to iCloud HSMs that the user entered the correct pin, without ever sending it over the wire. The HSMs have similar protections for brute forcing, etc.

From the docs I have a fairly high confidence entropy is 256 bits for iCloud Keychain. I have much less confidence on Android, but I'm still researching... :)

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

#175

Post by 015a »

awaythrow98765 wrote: post #57

Those passkeys are either insecure or unreliable. Let me explain: Those passkeys are asymmetric cryptographic keypairs where the private key is securely stored on a device, unlockable (for use, not reading) only by convincing your devices security processor to do so by pin/fingerprint/pattern. Which in itself can be secure, given you do trust that magic security processor (which you shouldn't, see yesterday's news fo…

It would be a bad and dangerous idea, if what you said was true; but it isn't.

Passkeys are just asymmetric key-pairs. There will be a variety of client-side implementations. Some may make export and backup difficult or impossible. Others, such as 1Password's already extant implementation advertise backup and synchronization as a feature! There is nothing about the passkey standard which prescribes the reality you fear.

> Now one could allow backups of a passkey, but then that passkey would be as insecure as a password.

Wrong, absolutely and entirely. Its still more secure, because its an asymmetric keypair, and you're forgetting about the far more common attack vector against password disclosure: service breaches. That's how attackers learn about passwords by-and-large. And this is not just some nice-to-have side-benefit of passkeys: its a core motivation of this standard. With passwords, a service breach compromises not only the accounts of every user on that service, but potentially every other account every user has, globally, because of password sharing. With passkeys, all of that is resolved.

Even if we end up with a system that is the same level of effective client-side security, which is also extremely wrong, the net security of the system will be vastly improved because service providers aren't storing the private key used to authenticate user accounts.

But the client-side security is also substantially improved, because passkeys have much higher phishing resistance.

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

#176

Post by tommiegannert »

I just started looking into WebAuthn this week, and was annoyed that there is no simple way to begin: Chrome (on Ubuntu) doesn't provide a local authenticator, unless you use an emulated one. This means any site that wishes to use WebAuthn can't just say "let's do it for everyone," because not everyone might have a phone they want to use, or a security key.

I found out [1] that WebCrypto + IndexedDB is pretty much the missing piece, where you can store/retrieve a generated CryptoKey without having access to the private data. I wish the WebAuthn API would handle that for me...

The end-result is likely that everyone is using WebAuthn as a 2FA, rather than a password replacement, because on-boarding seems to suck right now.

[1] https://stackoverflow.com/a/49479890

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

#177

Post by lxgr »

dcow wrote: post #171
lxgr wrote: post #153

Earlier quoted context omitted.

> use this to tether and lock you in to their platform. You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true. Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome insta…

You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just…

> the scenario where your password manager is running on the same device as the one where the user is performing the login

Android will provide an API for that scenario (i.e. on-device third-party authenticators) in the near future [1].

Hopefully, iOS will do the same.

[1] https://developers.google.com/identity/passkeys/supported-en...

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

#178

Post by sebk »

dblitt wrote: post #91

I still don't understand how the QR code flow works with using/creating passkeys on other devices. It seems it uses a bluetooth connection to your phone, but I can't find much documentation about the exact protocol

It's called hybrid transport, and the old name for it was caBLE. Yubico has a nice explainer here: https://developers.yubico.com/WebAuthn/Concepts/Hybrid_Flows... It's not fundamentally different than other transports for other roaming authenticators like a USB key; the QR code sets up a BLE connection between both devices and presents the authenticator with a challenge for it to sign and log in the originating device.

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

#179

Post by dcow »

SadWebDeveloper wrote: post #173

This looks and feels like passwords with extra steps... I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built. What happens if i lost all…

The solution, for you, is a cloud synced passkey manager, possibly a custodial one.

A password manager with strong passwords is weaker than a password manager with passkeys, because passkeys use asymmetric crypto and passwords+2fa involve exchanging a shared secret over an insecure channel at some point (yes I'm considering 1-sided TLS an "insecure" channel here).

Trust the security experts when they say passkeys are more secure. Now, solving the UX to make it match that of passwords plus managers today is the problem, agree.

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

#180

Post by lxgr »

transpute wrote: post #152
toomuchtodo wrote: post #140

Earlier quoted context omitted.

How is this different than a password manager with encrypted cloud backup? Your recourse if someone breaks passkeys is legal, not technical. Security must be a balance with functionality, and this is a huge improvement over passwords. (Tangentially, it would be great if we got cryptographic digital identity cards like Estonia has for signatures but that’s more of a long term goal) Cloud sync (encrypted!) is important…

> Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator Local-only iOS+macOS Codebook sync (open-source encrypted! by SQLCipher) provides password and TOTP convenience, durability, transparency, decentralization and fewer supply chain dependencies with one-time purchase. Founded in 2005. https://www.zetetic.net/codebook https://github.com/sqlcipher/sqlci…

> password and TOTP convenience

Passwords and TOTPs are not MITM-safe, WebAuthN/Passkeys implicitly are. (Credentials are bound to a specific RP, i.e. it's impossible to accidentally provide one to the wrong website or a scammer on the phone.)

Post reply on HN