Live data from Hacker News

Passkeys: The beginning of the end of the password

blog.google

151–160 of 1001 posts

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

#151
post #38

Just a heads-up if you're planning to use passkeys with iOS/macOS: Might be fixed already, but last time I tried it out it seemed like iOS only stored a single passkey per domain. If you first store a passkey for a@domain and then later on store a passkey for a different user b@domain the a@domain passkey is overwritten without any warning. Or at least this seemed to be the case a couple of months ago when I tried it…

That would only happen if the site isn't properly giving the passkeys identifiers. Having single passkey/username combo is working as intended, but it shouldn't be overwriting different usernames.

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

#152
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…

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/sqlcipher

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

#153

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 instance via QR/Bluetooth.

There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2.

[1] https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-cl...

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

#154
I don't know if this is the correct tactical implementation, relies upon having a cloud-based account that never goes away or gets disrupted in any fashion etc etc etc etc.

However! If you have built any product which has gotten traction, you know just how much of a pain auth still is in 2023. It will always be your number one customer service pain point -- either unable to remember the email address your users signed up with so they can't initiate a reset password flow, or not getting an OOB email to start said flow, and so on. Auth in its current state is a complete drain on company time, resources, and money. Extrapolating out, I really wonder what a raw cost of the world's total GDP is taken up by dealing with auth issues.

Any kind of breakthrough here would be such a net benefit to the human race as a whole. Even the half step of OAuth, even with all of its complexity and "did I use Google or Facebook or Apple to sign into this site?", even that reduced friction enough to be such a material benefit to customer service. If we can make signing into a service as easy as unlocking your phone, there would be a huge productivity jump.

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

#155
post #142

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…

The difference is that I can choose my password manager on iOS (and thereby pick my desired security level for password synchronization or opt out of it completely), but not my Passkey synchronization backend: iOS forces these to be stored in iCloud Keychain. (Passkeys are unavailable without iCloud Keychain [1]!) Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time. > Securi…

I agree there should be a way to opt out of system level ecosystem passkey sync with a big ol’ “you’re fucked if you don’t back these up somewhere” click through warning.

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

#156
post #142

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…

The difference is that I can choose my password manager on iOS (and thereby pick my desired security level for password synchronization or opt out of it completely), but not my Passkey synchronization backend: iOS forces these to be stored in iCloud Keychain. (Passkeys are unavailable without iCloud Keychain [1]!) Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time. > Securi…

> The difference is that I can choose my password manager on iOS

This is what you expect when you buy into the closed Apple ecosystem.

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

#158

Dumb questions: 1. what's the backup login mechanism when you lose your mobile device? 2. with Passkeys enabled/used, will this stop google from randomly locking my account because I happen to be a person who travels a lot and they constantly think I'm a fraudster attempting to log into my own account. 3a. can I use my google passkey for logging into non-Google sites? 3b. can I use my google passkey (biometric) to lo…

> 1. what's the backup login mechanism when you lose your mobile device?

Passkeys are synced to the cloud by default on iOS and Android, which is probably a good idea for many use cases, but might not be what you want in some instances.

> will this stop google from randomly locking my account because I happen to be a person who travels a lot and they constantly think I'm a fraudster attempting to log into my own account.

Probably not, but it will make it much easier to log back in – you won't even need to type your password if you use a 2FA-capable authenticator/passkey.

> 3a. can I use my google passkey for logging into non-Google sites?

No, a Passkey is bound to a website. But you can create as many of these as you want.

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

#159
post #142

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…

The difference is that I can choose my password manager on iOS (and thereby pick my desired security level for password synchronization or opt out of it completely), but not my Passkey synchronization backend: iOS forces these to be stored in iCloud Keychain. (Passkeys are unavailable without iCloud Keychain [1]!) Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time. > Securi…

Yeah this is fair. It blows my mind that platform players don't understand that the security posture needs to be configurable at a per-credential level. The hope would be that 3rd parties step in and provide implementations that afford these options to users, but that would require platform players to stop dragging their feet on allowing PW managers to hook in to WebAuthN challenges as a credential store/backend.

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

#160

> the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN I am not a cryptographer: why would a 6-digit screen lock PIN with this system be any safer than a 6-digit numeric password on the web (i.e. not very)?

If your physical device can be unlocked remotely with a 6 digit number, not much, but that's not generally the case.
Post reply on HN