Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

It's the second one, not the first one.

The protocol is private key stored on your hardware; public on the service you're authing to. Google doesn't have a way to MITM that, but if you lose the machine storing the private key, best have another way to auth.

(Note: some implementations, including Chrome on Android, do allow sync and sharing of the key, but IIUC even if Google bars you access to your account, the phone will still have the private key and can still do the login).



"best have another way to auth"

right, so passwords it is then.


well, the argument is that for strong passwords you will need to use a password manager anyway. Which you will sync somehow, which will sync your passkeys too. So in the end you might as well replace all your passwords with passkeys except for the one password you use to access your passkeys in your password manager / the master access basically. The one way to make sure that you never lose access. I think this makes sense, I'm also very dependent on a password manager now.


> the phone will still have the private key and can still do the login

One of the main gripes people have is about whether or not the user actually has access to the key or not.

ie. Can I save my passkey somewhere that I control, can I login on another device, etc. etc. Or do I need google's sync/account to do that for me.


Unless there is proof that the hardware on the phone is isolated specifically for this task you cannot make the claim that google is unable to MITM.


Yes, the hardware vendor that controls the kernel and chips can do whatever they want. I meant there is no method as per the definition of the protocol to MITM the passkey because the device only ever emits the public key unencrypted.


> Google doesn't have a way to MITM that

Google controls the software so it can MITM.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: