Live data from Hacker News

Passkeys are now enabled by default for Google users

blog.google

561–570 of 684 posts

Re: Passkeys are now enabled by default for Google users

#561

Lauren Weinstein is sounding the alarm on passkeys which is flawed and that it would make a huge headache for a lot of people especilly normal folks. https://mastodon.laurenweinstein.org/@lauren/111103819626952... https://mastodon.laurenweinstein.org/@lauren/111211366080459...

To me, it's unclear what the headache is. If the argument is about the consequences of passkeys for most ordinary people, most people are signed into their google account on their mobile device. In that case, your account is compromised anyway if your device authentication is breached.

For Google in particular, password/passkey isn't a binary choice(currently). You can fall back to the password sign-in flow if your device doesn't have a passkey.

Re: Passkeys are now enabled by default for Google users

#562

Earlier quoted context omitted.

Other businesses have humans on staff which will verify your identity documents. Google simply chooses not to do this, because it is expensive, and their "users" are not their customers.

Right, then you can just pay for Google's rather affordable non-free business version. Then you'll get reasonable support, well-reputed support.

I get a call from Google One Support. I explain the situation. They tell me to go to g.co/recover to recover my account (I already did this on my own). Same thing happens as before - same two options are given.

Then I'm told Google has a very strict security policy, and accounts cannot be changed in any way by support. So going through the recovery process is the ONLY way back into my account. So the call ends with them saying "I'm so sorry I can't help you." [1]

[1]: https://www.linkedin.com/pulse/when-you-get-locked-out-your-...

Re: Passkeys are now enabled by default for Google users

#563
post #552

Earlier quoted context omitted.

I haven't heard anyone claim that passkeys are simpler than passwords, as that would be trivially false. The claim is that they're more secure while still remaining fairly usable. Passkeys are WebAuthn credentials that are synced between devices, so they aren't hardware keys, they're software keys.

> more secure "more secure" is a completely meaningless statement, I wish this usage would die already (in general). You need to talk about security in the face of a very specific threat, then you can say solution A is better than solution B against threat T1, worse for T2 and about a wash for T3 and so on. Security is not a linear scale from 0-100 where you can say "more secure". There are many different criteria an…

The most problematic and the most probable security risk I have relating to logins is losing access. It for example took a week to restore access to my Apple account after I had forgotten to update my phone number there.

Since this is the greatest security problem, I would hope all the vendors trying to improve security would focus on that.

Re: Passkeys are now enabled by default for Google users

#564

Earlier quoted context omitted.

How does this address OP's concern? If you have a single device (e.g. an iPhone) and you store all your passkeys on it, then losing it means you lost all passkeys. Your post describes exactly that: - "I can’t recover the keys if I lose the hardware" - "That is a risk you’ll need to take if you’re using hardware authenticators" Fantasizing that with this proposed simplification of the authentication process people wil…

I haven't heard anyone claim that passkeys are simpler than passwords, as that would be trivially false. The claim is that they're more secure while still remaining fairly usable. Passkeys are WebAuthn credentials that are synced between devices, so they aren't hardware keys, they're software keys.

They are not more secure from a cryptographic standpoint. There are different attack vectors and for some passkeys are superior but in others they are certainly not.

Additionally, part of the security concern is also accessibility by yourself.

edit: Just tried the Google passkeys on one of my Android phones. It is a complete usability hell and it seems I cannot opt out again without logging in from my browser and deleting my "device". If there is another way to just do it from my device without an additional browser, please tell.

Re: Passkeys are now enabled by default for Google users

#565

Earlier quoted context omitted.

For that reason I don't want passkey. Password and regular 2fa/totp are fine... when setting 2fa I put it on my phone and my computer and another password vault on rpi... granted, everything still in same location but still somewhat better. I'm not really sold on esim neither - regular sims let you pop and swap them easily... why complicate it?

>Password and regular 2fa/totp are fine This might feel true, but it's factually not true. Both passwords and TOTP can be phished. In addition, passwords can be weak, reused, and password hashes can (and are frequently) stolen and cracked in server breaches. Passkeys are guaranteed to be strong, unique (can't be reused), strongly phishing-resistant, and there's nothing worth stealing from servers (just public keys).…

pros and cons to each approach

Re: Passkeys are now enabled by default for Google users

#566

Earlier quoted context omitted.

A main idea of passkeys is that the private keys are bound to hardware and cannot be copied. Using the private key is subject to biometric authentication. This eliminates a whole category of issues where the private key could get stolen. So no, writing down the SSH private key is not the solution. The solution is to trust multiple private keys, each stored within tamperproof hardware. This is also why, as a service p…

It sounds like I am up the creek if all of my devices are gone. With a bank, if I lose paperwork, they will have a process in place for me to prove my identity. BigTech will shrug if my phone-locked passkey becomes inaccessible.

The initial poster described that process - you bring government IDs in person to an office.

If you want to avoid that, just set up multiple devices.

Re: Passkeys are now enabled by default for Google users

#567
post #552

Earlier quoted context omitted.

I haven't heard anyone claim that passkeys are simpler than passwords, as that would be trivially false. The claim is that they're more secure while still remaining fairly usable. Passkeys are WebAuthn credentials that are synced between devices, so they aren't hardware keys, they're software keys.

> more secure "more secure" is a completely meaningless statement, I wish this usage would die already (in general). You need to talk about security in the face of a very specific threat, then you can say solution A is better than solution B against threat T1, worse for T2 and about a wash for T3 and so on. Security is not a linear scale from 0-100 where you can say "more secure". There are many different criteria an…

Threat #1: Credential theft from server breaches

Threat #2: User creates a weak credential

Threat #3: User reuses a credential (uses same credential across multiple services)

Threat #4: Phishing

Attackers use huge password dumps compiled from multiple server breaches, and then try them against other services. Relying on a combination of the fruits of their labor from all four threats, attackers successfully compromise millions of accounts on the internet every year.

If you want to see the data, check out the Verizon Data Breach Investigation Report that comes out every year.*

These threats affect a majority of both consumers and enterprises.

Passkeys address all four of these major real-world threats. Passwords address none of them.

Threat #1 mitigation: with passkeys, only a public key is stored on the server. Attackers can steal all the public keys they want; it will not help them compromise any user's account.

Threat #2 mitigation: passkeys (which are WebAuthn credentials) are guaranteed to be cryptographically strong. It is not possible for a user to generate an insecure passkey. This is because the browser the the Operating System APIs take care of generating the credential.

Threat #3 mitigation: passkeys (which are WebAuthn credentials) are guaranteed to be unique. It is not possible for a user to reuse the same passkey across multiple apps/websites. This is because the browser the the Operating System APIs take care of ensuring that a new, unique credential (passkey) is generated for every new app/website the user sign's into.

Threat #4 mitigation: passkeys (and all WebAuthn credentials) are bound to the server FQDN at the time they are created. The browser and Operating System APIs take care of ensuring the credential is only ever sent to the app/website server it was created for. Users cannot be tricked (via phishing) into using their passkey on a malicious app/website controlled by an attacker.

* https://www.verizon.com/business/resources/T249/reports/2023...

Re: Passkeys are now enabled by default for Google users

#568

Earlier quoted context omitted.

> Very much this. Having authentication tied to hardware you don't control is a near-certain denial of service in the future. Then you can tie it to hardware you do control, or to software. Obligatory "Passkeys misconceptions" article: https://www.stavros.io/posts/clearing-up-some-passkeys-misco...

How does this address OP's concern? If you have a single device (e.g. an iPhone) and you store all your passkeys on it, then losing it means you lost all passkeys. Your post describes exactly that: - "I can’t recover the keys if I lose the hardware" - "That is a risk you’ll need to take if you’re using hardware authenticators" Fantasizing that with this proposed simplification of the authentication process people wil…

“Hardware vendors helpfully suggest buying more hardware as a solution to a problem they introduced.”

Re: Passkeys are now enabled by default for Google users

#569

Earlier quoted context omitted.

>Password and regular 2fa/totp are fine This might feel true, but it's factually not true. Both passwords and TOTP can be phished. In addition, passwords can be weak, reused, and password hashes can (and are frequently) stolen and cracked in server breaches. Passkeys are guaranteed to be strong, unique (can't be reused), strongly phishing-resistant, and there's nothing worth stealing from servers (just public keys).…

pros and cons to each approach

What are the pros to using phishable passwords and 2FA?

Re: Passkeys are now enabled by default for Google users

#570
post #449

Earlier quoted context omitted.

> made even worse by it being treated as equivalent to password+2FA. passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks. A passkey alone is much more secure than the vast majority of password + 2FA combinations. The only thing stronger than a passkey standing alone is a Security Ke…

> passkeys are significantly more secure Blanket statements like this demonstrate a misunderstanding that "security" is just one thing in a single lineal scale. In reality you have to ask, secure against what? And to answer that meaningfully you need to a thorough threat model for the specific use case of person P and account A. The same person P will have a different threat model for every account they have. The D i…

I'm not sure why you didn't include the rest of the sentence, which made it clear that I was making a very specific comparison to password + phishable forms of 2FA. I was very clearly not making a blanket statement.

Here's the full context again:

passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks.

>The D in STRIDE is for denial of service. Passkeys are much worse on this axis than any other solution. You need to evaluate for the specific combination (P,A) how much this matters vs. other criteria.

How are passkeys (really, WebAuthn credentials in general) any worse in terms of denial-of-service attacks than passwords?

I think you're trying to make a point about specific passkey/password managers, rather than the actual credentials themselves. Is that accurate?

Post reply on HN