Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passkeys are now enabled by default for Google users

blog.google

Post reply on HN
Print view View original

381–390 of 684 posts

Re: Passkeys are now enabled by default for Google users

#381

Post by redrblackr »

jiggawatts wrote: post #339

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…

EDIT: I assumed passkeys refer exclusively to hardware passkeys, mb. My answer below means separate HARDWARE "security keys", not ones tied to a smartphone, Google or Microsoft account...

The problem here is that you are assuming one passkey. Just like you don't get just one key for your door its risky to get only one passkey, if you are planning to use it exclusively.

Passkeys are like normal keys but for your digital life. They have many benefits over normal keys like being impossible to copy/pick while still being easy to replace (as long as you have one that works) and if used properly (with a short pin-code) someone who finds or steal your key cant log in to your virtual doors anyway. They compare even better to passwords.

Just get one for your keychain and one to put at your stationary computer at home. The only thing to remember is to add both to your account(s), which still is faster than fiddling with your password manager and/or second factors.

Passkeys are really amazing, the only thing(s) remaining is to stop confusing people with terminology, explain that you should have a pair and for services to start properly using the keys as a combined first+second factor with a pin (which you can have safely the same on all your passkeys, in contrast to passwords).

What do you mean not cross-vendor transferable? You can use any brand key that properly implements the protocol (fido2/webaunth), and replace them with any brand key. If you mean copy them, well yea that's kinda the point..

There are plenty of ways for recovery on reasonable services, sometimes they ask to set up way to many (and with multiple passkeys, recovery is only relevant if you loose ALL of your keys).

Just want to point out that if your missus had a pair of passkeys there would not have been any issue!

Re: Passkeys are now enabled by default for Google users

#382

Post by brundolf »

jiggawatts wrote: post #339

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…

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

Re: Passkeys are now enabled by default for Google users

#383

Post by maxwellg »

LeoPanthera wrote: post #255

1Password enabled PassKey support recently and I was "surprised" to learn that there is no way of exporting them out of 1Password. They're not included in the 1PUX format export, nor in the CSV. That means that they're literally impossible to back up. If 1Password goes down, or the company stops operating, or anything else like that, your Passkeys are just... gone. Absolutely no way to recover them.

1Password's Passkey support feels very aggressively growth-hacky to me. They intercept calls to `window.credentials` and if you want to use 1Password along side other verifiers like Yubikey, you need to go into your settings and disable their passkeys offering entirely. It's similar to how they also intercept (and globally disable!) Google One Tap prompts in order to show their own OAuth prompt. I only use their Chrome extension so I'm not sure if the native app experience is significantly different.

Re: Passkeys are now enabled by default for Google users

#384

Post by latchkey »

Macha wrote: post #377
latchkey wrote: post #375

Earlier quoted context omitted.

Again, that's not a requirement for a phone number. That's asking a user to verify themselves with a provided number . Likely because the user doesn't have anything else set up for 2FA.

This is not true. It will ask for a provided number if you've already provided one, but if you've never provided one, it'll ask for any number and treat that as the provided number for future reference.

> This is not true.

What is not true?

> if you've never provided one

I started this thread off with don't provide a number.

Again, set up a alternate 2FA with them and you won't have to deal with a phone number at all.

> and treat that as the provided number for future reference

Even if they did add it in, you could remove it later.

Re: Passkeys are now enabled by default for Google users

#385

Post by brundolf »

verytrivial wrote: post #248
rawgabbit wrote: post #226

While I believe this is a step in the right direction. I have read too many horror stories of people who were locked out of their Google and iCloud accounts with no real possibility of getting back in. I don’t think I am alone in thinking I am on borrowed time. Someday, probably due to my own fault I will be locked out of Google and my digital life will be over. If a private company can offer a similar login method l…

Disaster recovery. This is 100% my biggest worry with 2FA/MFA. I also think this is one of the reasons stuff like PGP never took off (don't @ me regarding perfect forward secrecy): the problem has always been managing some little, precious thing and the ramifications of what happens if it put beyond use or is used by some bad actor.

I feel okay with Authy because I've got synced across multiple devices; one I bring out into the world and one I usually don't. I would be pretty nervous if I didn't have a second eligible device though

Re: Passkeys are now enabled by default for Google users

#386

Post by selcuka »

Shank wrote: post #364
jiggawatts wrote: post #339

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. I believe all of the issues you've described, but you can usually add multiple passkeys to each service. There is nothing stopping you from adding your iPhone and a cheap android phone and having redundancy, or using 1Password and storing your passkey in there. iPhone back…

There are workarounds, but that doesn't mean that passkeys is a half-baked technology. The real, simple solution would be a way to write down the passkey, similar to an SSH private key.

Re: Passkeys are now enabled by default for Google users

#387

Post by Macha »

latchkey wrote: post #384
Macha wrote: post #377

Earlier quoted context omitted.

This is not true. It will ask for a provided number if you've already provided one, but if you've never provided one, it'll ask for any number and treat that as the provided number for future reference.

> This is not true. What is not true? > if you've never provided one I started this thread off with don't provide a number. Again, set up a alternate 2FA with them and you won't have to deal with a phone number at all. > and treat that as the provided number for future reference Even if they did add it in, you could remove it later.

> What is not true?

The claim that google will never insist you set up 2FA by providing them a phone number if their ML algorithms decide your log in is suspicious.

Based on my own experiences with a little used google account and finding the messages of other users who have encountered the same error.

What is your basis for claiming that my position is untrue?

Re: Passkeys are now enabled by default for Google users

#388

Post by jesseendahl »

ktosobcy wrote: post #345
jiggawatts wrote: post #339

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…

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).

Passwords and TOTP are not fine, they're both fundamentally broken when you look at them in the context of the modern internet attack landscape.

Re: Passkeys are now enabled by default for Google users

#389

Post by jesseendahl »

hbt wrote: post #371
jiggawatts wrote: post #339

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…

what you are describing is why I use a virtual phone for all services. you can do it on your own with twilio, then create a phone number and have a program forward you stuff to your real phone. the twilio phone is hard to lose as it has an api and you can toss it when you want to start over. except now, you need an entire phone virtualized as your proxy instead of just a twilio phone number. they keep raising the bar…

This provides significantly weaker account security than using a passkey. 2FA codes delivered over SMS can be phished.

Re: Passkeys are now enabled by default for Google users

#390

Post by metafunctor »

selcuka wrote: post #386
Shank wrote: post #364

Earlier quoted context omitted.

> 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. I believe all of the issues you've described, but you can usually add multiple passkeys to each service. There is nothing stopping you from adding your iPhone and a cheap android phone and having redundancy, or using 1Password and storing your passkey in there. iPhone back…

There are workarounds, but that doesn't mean that passkeys is a half-baked technology. The real, simple solution would be a way to write down the passkey, similar to an SSH private key.

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 provider, I'd like to see some device attestation. I want to know that the keys being used here are not written on a fucking piece of paper.

Post reply on HN