Live data from Hacker News

Passkeys are now enabled by default for Google users

blog.google

571–580 of 684 posts

Re: Passkeys are now enabled by default for Google users

#571

Earlier quoted context omitted.

Passkeys and u2f keys aren't the same. Systems must support multiple passkeys, otherwise you could only access the service from a single device, since passkeys are usually tied to a particular piece of hardware.

Nevertheless, nothing forces my banking app to accept a second PassKey other than the one linked to FaceID. When I buy a new phone, I need to re-bootstrap auth from zero. There’s no way to store two.

Is the app the only way you interface with your bank? It doesn't have a website?

All of the things I've used passkeys on support both web and mobile auth, which necessitates two keys.

Re: Passkeys are now enabled by default for Google users

#572
post #209
post #95

Earlier quoted context omitted.

The vaults have been adding passkey support (1Password already has it, for instance).

I will never willingly go back to using 1Password.

I see the 1Password social team is still around downvoting people who speak their minds.

Re: Passkeys are now enabled by default for Google users

#573
post #432

As others have pointed out, cryptographic authentication is very hard to bootstrap if you simply loose your device. Just last month my missus cracked the glass of her iPhone. Apple repaired it under AppleCare, which is great… except … that they didn’t tell her that the “glass repair” entails them replacing the guts of the phone and wiping it in the process. Apple iPhone backups don’t contain cryptographic secrets lik…

> Run away screaming. Don’t believe the hype. Wait until the vendors get their act together and come up with a solution for transfer and recovery. Very much this. Having authentication tied to hardware you don't control is a near-certain denial of service in the future. People love to hate on passwords but the reality is that for many circumstances (threat models) they are the best compromise. You can make them more…

> People love to hate on passwords but the reality is that for many circumstances (threat models) they are the best compromise. You can make them more than strong enough (take 32+ bytes out of /dev/random and encode however you like, nobody will ever brute force that in this universe) and various passwords managers solve the problem of re-use (never reuse a password).

> And it comes with the benefit that you control how it is stored and can apply as much redundancy as you want to feel comfortable.

Honestly, I agree!

I used KeePass back in the day (https://keepass.info/) but now use KeePassXC (https://keepassxc.org/) and it's really nice - I don't know any of my passwords because they're all randomly generated and are pretty secure, in addition to them being unique for every account. The only one I have to remember is my main password for decrypting the safe, which I also wrote down and entrusted to someone close to me due to its complexity.

It honestly works great, software to interact with the password safe is on every platform where I need it to be, in addition to it being super easy to reason about storage, because it's basically just a file - that I can then put on self-hosted Nextcloud, or another solution like that, or USB sticks or burn to CDs for all I care.

Maybe I should also migrate all of my TOTP stuff over to it and look into good Android apps at some point, then I wouldn't quite need Google Authenticator or FreeOTP anymore, either.

Re: Passkeys are now enabled by default for Google users

#574
post #65

Simpson's Paradox lives here. On average, this might increase security (the vast majority of users are terrible at using passwords). For proficient users who use passwords securely, this is an acute drop in security (if forced to use). Forced phone number 2FA has the same effect; in Big G's case forcing phone number 2FA is anti-anonymity disguised as security. In this case, it's a bid for biometrics.

> For proficient users who use passwords securely, this is an acute drop in security (if forced to use). Why? Because the user can have their device stolen and the PIN guessed? Can't you use a long password instead of a PIN if you want to? And this part I'm not sure of, please correct me if you know. If I understand it correctly there's one security advantage even assuming a sophisticated user who is immune to weak p…

I live in a country where my phone is forcibly tied to my identity. I will not use it to authenticate anywhere. For business purposes with my business phone perhaps, but certainly not for my private life. That would be a huge decrease in security.

Re: Passkeys are now enabled by default for Google users

#575
post #491
post #417

Earlier quoted context omitted.

Legacy contact https://support.apple.com/en-gb/HT212360 Account recovery contact https://support.apple.com/en-gb/HT212513

Can't add those after the fact.

Sorry, but that is a weak argument. Individually, people have to take responsibility for their security. The tools exist and are simple to use.

Re: Passkeys are now enabled by default for Google users

#576
post #286

Earlier quoted context omitted.

Currently, none of the big players in the passkey space support exporting or importing of passkeys, because the spec for doing this securely has not been agreed upon, and nobody wants to allow plaintext export of passkeys. See a recent post in the 1Password passkey AMA about this subject: https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd... Re. your point about 1Password going down: Your passwords and pass…

> nobody wants to allow plaintext export of passkeys. While noble, why? 1Password exports a plaintext file that has all of the credentials in plaintext already.

Because in this brave new world you aren't supposed to own your keys, some proprietary HSM inside your device does.

Re: Passkeys are now enabled by default for Google users

#577

Earlier quoted context omitted.

> If you don't trust them, you're not forced to use them; traditional methods still exist. I predict this will not be true always.

Yes, the security industry is probably going to shift massively to Passkeys over the next few years. Phishing is a massive issue for enterprise security, and Passkeys basically completely fix it. IMO, this also means the problems with Passkeys will get fixed pretty quickly. And given I can already store my Passkey in 1Password and then use it on every device I currently use (including Firefox on mac/windows and iOS S…

If passkeys evolve by enterprise requirements it sounds unlikely you'll be able to ever properly export your keys. Instead, you'll get forced attestation to make sure you're not using Linux or some other untrustworthy platform.

Re: Passkeys are now enabled by default for Google users

#578

Earlier quoted context omitted.

Honestly, if they'd just give me the option to write it down (or take a picture or whatever) and manually restore it by typing it in if I need to, that would just about solve the issue

I like this idea of authenticating yourself by typing things in.

And it would be completely independent of vendor or device. Should write a paper on it.

Seriously, just tried passkey on an Android phone of mine with a burner account. I would not recommend this to anyone. Passkey as a tech might not be the issue, but the lacking option of just removing devices and passkeys freely from your account is just not acceptable. The vendor simply has different ideas about security than I have and it is not just restricted to serving me "safer" ads.

Re: Passkeys are now enabled by default for Google users

#579
post #552

Earlier quoted context omitted.

> 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 compromis…

You are correct about all of that.

But personally, as a technically able user, my risk of randomly losing access to my Google (or MS, Apple, Meta, etc) account is far greater than from all those threats combined.

If we had a trustworthy and accountable authority operating this stuff then it would be great. But we don't, we have a bunch of companies who are neither of those things.

It's like mandating that everyone must use self-driving cars that are on average safer than human motorists but occasionally randomly drive off a cliff.

Re: Passkeys are now enabled by default for Google users

#580
post #530

As others have pointed out, cryptographic authentication is very hard to bootstrap if you simply loose your device. Just last month my missus cracked the glass of her iPhone. Apple repaired it under AppleCare, which is great… except … that they didn’t tell her that the “glass repair” entails them replacing the guts of the phone and wiping it in the process. Apple iPhone backups don’t contain cryptographic secrets lik…

The solution to your problem is simply more passkeys. I am not being sarcastic - which ever service your authenticating to make sure you have passkeys from at least 2 different devices so you do not lock yourself out. If you don't fit into this multi device assumption, passkeys are not going to work well for you. There will not be a standard for transfer / recovery.

That is completely unrealistic to me. The normal users will not register different devices and will simply be locked out when the device fails or is lost.

And the question they will ask is about the need to have two passwords.

Post reply on HN