Live data from Hacker News

Passkeys: The beginning of the end of the password

blog.google

261–270 of 1001 posts

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

#261
This is a good start, but like everything Google introduces, it's only designed to be useful to Google, and has a number of flaws:

- syncs to the cloud without E2E encrypted. there's no reason any person should ever put all their private keys somewhere they can be stolen without at least a secret master password protecting them.

- they're not one standard. web apps will use WebAuthN, non-web apps will use a FIDO API. Passkeys are a mix of different technologies that is more complex than needed.

- they aren't interoperable with different software and devices. Currently, if you make a passkey, it can only work with whatever you used to make it. trying to use a passkey on different operating systems or apps etc requires manual workarounds, exporting/importing, etc.

- different providers have different levels of support. some support sign-in, some support MFA, some support both.

- the choice of only being able to use biometrics or a pin to protect the passkey store is stupid. you should be able to enter in text as well, so you can use a long and complex key to protect it, if you want. instead your options are 3 incredibly easy to crack methods.

- there isn't an easy way to back up everything offline in case your devices get lost.

- all this doesn't address attacks on account recovery, which is the most common way to compromise an account (nobody brute-forces passwords anymore, with the exception of giant password compromises which are used for lateral attacks against other services)

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

#262
post #40
post #5

How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits. Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.

Password + password manager can be trivially phished. PIN can’t, because even if you somehow phished a user you can’t use it. I don’t know what “proper 2FA” means but the gold standard today is U2F, and it has failed to be mass adopted due to requirement to purchase and maintain another device.

FWIW, my password manager has prevented me from being phished because it wouldn't auto-fill the password.

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

#263
post #142

Earlier quoted context omitted.

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…

Okay so use a YubiKey? I must be missing something but I do not get all this hand-wringing. Don’t like the passkey options from Google or Apple? Fine! Use the hardware authenticator you absolutely already have if you’re the kind of person who has these sorts of objections.

Sure, I already do that, but why shouldn't there be a choice in on-device passkey implementations just like there is for password and HOTP/TOTP authenticators?

Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS. There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.

It would encourage competition in both functionality and security, it reduces reliance on a single account your entire digital life, it allows niche products to address special requirements in all kinds of scenarios...

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

#264
post #28

I really wish these “password killers” would acknowledge that we will never eliminate passwords. Ever. There’s too many under-funded applications deployed out there that have no resources to add passkey support. Password managers are an excellent place to progressively enhance the user authentication story and could support more advanced schemes like passkeys while remaining compatible with the registry of deeds site…

Yeah, none of big tech wants that, they don't want to make it easy for 3rd party.

Ideally there would just be standarized interface between "credential manager" and applications + some OS-enforced security (so password manager knows which PID sent the question about password or other type of credential).

Then we could have say pub/privkey or cert based authentication implemented there, app just asks for a credential for a site and cred manager asks user whether to allow it once or forever, and which credential to give.

The app then could garnish that with extra metadata so say firefox container feature, or different firefox profile could attach metadata about from which container or profile the request comes from, and credential manager could hand out different credentials based on from where it came.

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

#265
When a company rolls out something new and exciting that will improve your life, ask yourself: why are they spending money on this?

Just stuffing more of our private lives into phones full of ads and tracking. Each time you unlock your phone Google makes money.

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

#266
post #253
post #163

Earlier quoted context omitted.

Passkeys are an authentication mechanism, and as such replace (authentication) passwords, not (encryption) passphrases. A password (at least as I understand the term) is used to authenticate to some third-party entity to get access to your data or services. The (implied or legal) contract here is: "Only give access to my data to anybody that can provide my password." Government authorities can in most cases just go t…

Great! Where I can type those passhphrase in google mail or o365 or million other serivces to secure my data ? Oh? Nowhere? Then why you're even talking about the distinction ? Also passphrase definition is definitely not "a password used for encryption", I dunno where you pulled that from. Original meaning is just "longer, more secure password"

> Then why you're even talking about the distinction ?

GP was talking about the legal implications of using a hardware authenticator vs. a password.

> Original meaning is just "longer, more secure password"

And where do you usually need a longer, more secure password? Encryption (as opposed to authentication, where you can often rate-limit attempts) immediately comes to mind.

> I dunno where you pulled that from.

From https://en.wikipedia.org/wiki/Passphrase:

[...] , especially those that derive an encryption key from a passphrase [...]

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

#268
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 vendor by default (i.e. Google or Apple, and soon also third-party password maangers on Android) That's a showstopper for me, personally. Not saying the idea is a bad one (at all!), but I won't be using it for myself.

Me too – I'd much rather trust my password manager, so I'm hoping that platform/browser APIs will eventually become available that will allow such third-party implementations. (Android is planning to; iOS hasn't stated anything yet.)

Even then I would probably not add my bank credentials or other high-sensitivity things there.

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

#269
post #186

Earlier quoted context omitted.

My cynical assessment of Passkeys is: If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere. This isn’t a theoretical risk. You’ll see lots of people complain about this online. Also, Passkey providers now get sweet sweet metadata about your accounts around the web. But yeah, authn is hard to do right. Equally, asking your users to fall into $BIG_PROVIDER’s arms seems wrong. My pe…

> If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere. Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co. ("roaming authenticators" in WebAuthN/FIDO parlance). Unfortunately, only Android is planning to offer [1] a first-party Passkey provider API, because that's what I'll probably be using 99% of the time (finding my external authenticat…

> Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co

That’s good to know.

Although my concern would be, that’s really good for people who use YubiKeys, but regular people won’t, and they can then get bitten by account lockouts.

Is there something regular users can do to use Passkeys (let’s say they use Google) and have some recourse if Google locks them out?

Also, what happens if they use Android, have no other computing device (this is fairly common in some parts of the world), and their phone gets stolen?

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

#270
post #264
post #28

I really wish these “password killers” would acknowledge that we will never eliminate passwords. Ever. There’s too many under-funded applications deployed out there that have no resources to add passkey support. Password managers are an excellent place to progressively enhance the user authentication story and could support more advanced schemes like passkeys while remaining compatible with the registry of deeds site…

Yeah, none of big tech wants that, they don't want to make it easy for 3rd party. Ideally there would just be standarized interface between "credential manager" and applications + some OS-enforced security (so password manager knows which PID sent the question about password or other type of credential). Then we could have say pub/privkey or cert based authentication implemented there, app just asks for a credential…

> Yeah, none of big tech wants that, they don't want to make it easy for 3rd party.

iOS has an API for password managers and HOTP/TOTP authenticators. Android is planning to introduce one for passkeys.

Post reply on HN