Live data from Hacker News

Passkeys: The beginning of the end of the password

blog.google

231–240 of 1001 posts

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

#231
post #60

Earlier quoted context omitted.

Passwords are terrible for a world where people have hundreds of them and are lazy. And password managers are a bandaid solution. Arguing effectively that passwords were fine for computing in 1970 isn't an answer. So if you don't like passkeys it's reasonable to ask for your alternative.

The first point seems correct, the second seems incorrect. Remembering a single password for access to a secure well-designed password manager seems a bit more secure than a physical passkey, what am I missing?

Because password managers that you (and many others) use all the time are probably a more serious attack vector than your bank deposit box.

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

#232
post #189

Earlier quoted context omitted.

Passwords can be both stolen (they are valid for multiple authentications) and are susceptible to phishing/MITM attacks. TOTP/HOTP solves the first problem by making the credential provided during authentications single-use, but they're still susceptible to phishing/MITMs (since you don't know where you're entering your OTP). WebAuthN solves both. > What happens if i lost all my devices due to a fire? Passkeys are sy…

> Passkeys are synchronized to your device ecosystem ... and soon also third-party password maangers on Android And at that point they make a full circle becoming just passwords with a master password. Essentially what password managers already do. You already can tie a master password to a biometric or another factor.

Not quite: Passwords are long-lived bearer tokens, which can be phished/MITMed (exclusively using auto-fill helps, but non-technical users are still prone to be phished) and are administratively harder to securely manage on the backend of the relying party.

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

#233

Earlier quoted context omitted.

> Auth is as secure as the weakest link True if you are being specifically targeted, but there are whole classes of vulnerability that you are better off not having even if you have less than perfect opsec. To take an extreme example, my personal server may have an unpatched vulnerability that a determined attacker might exploit, but that doesn't imply I might as well share the same password across all my accounts.

> that doesn't imply I might as well share the same password across all my accounts Irrelevant to the argument I made. My argument already assumes you're using unique passwords, since it's made quite simple these days.

My example appears to have distracted you from the point I was making. Let me make the point again without an example: being vulnerable to one attack does not mean there's no value in not being vulnerable to another attack when the attacks require different strategies and levels of effort. Or again: making breeching security more difficult does in fact reduce your risk of random security breeches. Or to put it another way, a determined attacker will search for an opening, an opportunistic attacker will move on. There's value in protecting yourself from opportunistic attacks.

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

#234

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…

MPK is really cool.

> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.

The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you.

There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.

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

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

Can I store the keys in bitwarden or am I stuck using google chrome to access this or whatever Mozilla cooks up? I can't rely on retaining access to my Google account for logging into things.

On Android, there will supposedly be an API for third-party Passkey implementations soon: https://developers.google.com/identity/passkeys/supported-en...

1Password has already announced their intention to use this once ready. I really hope iOS will provide something similar soon.

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

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

Can I store the keys in bitwarden or am I stuck using google chrome to access this or whatever Mozilla cooks up? I can't rely on retaining access to my Google account for logging into things.

Not now, but soon. Bitwarden's public statements over the past year, and their acquisition of passwordless.dev, would seem to indicate that they're working very hard on adding passkey support.

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

#238
I'm curious to get a take on Apple's documentation for passkeys and iCloud Keychain Recovery Escrow system [1] [2]

There's multiple references in this documentation to phrases like "To sign in for the first time on any new device, two pieces of information are required—the Apple ID password and a six-digit verification code" or in the no-device-recovery escrow documentation: "users must authenticate with their iCloud account and password"

I can imagine a world where Apple replaces sign-in passwords with passkeys; your devices form a ring of trust which "sponsor" new devices into your end-to-end-encrypted iCloud Keychain. But I'm having a hard time imagining how zero-device escrow recovery can work without a thing-you-know password.

Has Apple spoken specifically on this at all? Do they intend to follow the same route as Google and get rid of passwords entirely, and if so how are they securing zero-device iCloud Keychain recovery? Or will they probably just keep passwords around, if only for this specific use-case; and if so, what are the implications for functional user security? If I have an Apple Password I don't use for ten years, then have to use it that one time to complete zero-device recovery, many users won't remember it.

[1] https://support.apple.com/en-us/HT213305

[2] https://support.apple.com/guide/security/escrow-security-for...

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

#239
I will never weld my login to a physically so fragile and unpredictably high maintenance and volatile thing as a mobile phone. It is also cumbersome for casual logins and increadibly risky for important ones. Thank you, but no.

(good thing I already started to migrate away from the Google universe)

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

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

The article says "Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN." Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs? As a user, that's sounding a lot like platform lock-in to me. And as a devel…

[deleted]
Post reply on HN