131–140 of 145 posts
Google does not care about FIDO or standards compliance. They care about vendor lock-in their proprietary passkey offerings allow.
Speaking of passkeys, could they be used to authenticate to a local application - say for unlocking a password vault (perhaps through a Yubikey)?
Passkeys are great because they get sync'ed to all your devices, which makes it really easy to share access to those websites with other people ( who have access to devices on your account ). Like a spouse.
You know what's even easier? Sending them the password.
Earlier quoted context omitted.
Just not having the right device with you is crippling. IMO Passkeys need more work. I'd really like to see accounts support multiple passkeys. I'd prefer biometrics that are device independent. I just don't like the idea of replacing something someone can steal (a password) with something else someone can steal (a phone).
Would be nice, but biometrics have also been systematically made less secure. Apple, for example, no longer sells a phone with Touch ID.
Earlier quoted context omitted.
Why is it more important than protecting users? They've already added a way to share them securely.
Wasn't the discussion you responded to about how they currently can't be shared and that the vendors don't want them to be shared as it breaks their desired lock-in?
Earlier quoted context omitted.
Correct, individual sites could make that choice. They won't, but they could. (Love the mention in the linked comment of Netflix and Disney, two services that don't even support proper MFA.) We're completely on the same side, to be clear. I just have zero fear of KeePassXC (which I sometimes use with Okta!) being blocked by anything consumer-facing.
Apple does precisely this for Apple account, you need to have a hardware attested passkey implementation to authenticate using passkey. Edit: forgot to add Apple account
Passkeys are great because they get sync'ed to all your devices, which makes it really easy to share access to those websites with other people ( who have access to devices on your account ). Like a spouse.
They certainly fucking don't.
I also have no interest in my credentials touching any cloud whatsoever.
Earlier quoted context omitted.
Would be nice, but biometrics have also been systematically made less secure. Apple, for example, no longer sells a phone with Touch ID.
Vendors not using biometrics well doesn't mean biometrics are insecure. Apple not selling touch ID CERTAINLY isn't evidence of the security of biometrics.
Of devices currently sold, the only secure biometrics I'm aware of are on iPad mini/Air; Google Pixel; Honor Magic; and possibly Samsung Galaxy S21 and newer.
> websites which [...] also want to know how the passkey is being handled by the user’s device to keep their accounts safe This is exactly where passkeys go too far. "to keep their accounts safe" is always the excuse used to reduce the freedoms of users. Web sites have no business deciding how things are handled on user devices but it's precisely what passkeys enable. The boundary of control of a website used to stop…
Yep the whole tpm thing and the device constrained nature they have envisioned is the major drawback. But no they have to live in their secured enclave or on a dongle so that you can't copy them between devices because nothing ever happened to a device. As if the rest of the users system is compromised the user can't be tricked into providing access to their account. And no one ever "recovered" someone else's account…
I'm actually fine with this. It's like how SSH private keys are supposed to be handled: generated on the device, and never supposed to leave it.
The proper way of doing Passkeys is to have several Passkeys enrolled in your account, so that you always have a trusted device to access your services. Now, if the service doesn't allow multiple Passkeys per account that IS a problem.
Earlier quoted context omitted.
> Or logging in to your bank without an iPhone or an android. This is already possible (and common!) many banking apps, for better or worse, use device attestation features that require varyingly official copies of android. Were you already complaining about this?
> Were you already complaining about this? Yes, "we" were, definitely. I already can't freely choose the OS that I have installed on my phone because I'm limited in the apps that I can install. For example many government ID and banking apps will refuse to work on GrapheneOS even though that OS is security-focused and will probably keep you safer than your regular Chinese Android flavor. But it's not sanctioned by a…
I am not unaware of the potential dangers of device attestation.
> Would you be ok if for example your government's website to pay your taxes mandated a device with attestation knowing you can only get one from Google, Apple or Microsoft ?
My point is this is already possible today. A lot of apps do it. An open attestation API means that, at least theoretically, systems not owned by one of those three providers could be used. Today you get, functionally, a signal of "this is blessed android or not". An alternative world where the device attests "I am grapheneOS" and it is up to the service to accept that attestation or not is strictly better than the ability today.