191–200 of 684 posts
Earlier quoted context omitted.
On iOS you can use third party software to manage passkeys, there is no inherent cloud requirement.
Source? >Note: To use passkeys, iOS 16, iPadOS 16, macOS 13, or tvOS 16 (or later) is required. iCloud Keychain and two-factor authentication must also be turned on. https://support.apple.com/guide/iphone/use-passkeys-to-sign-...
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.
Earlier quoted context omitted.
On iOS you can use third party software to manage passkeys, there is no inherent cloud requirement.
Can you? If so, this is great news. What apps support this?
Hottake here: The biggest mistake that the passkeys movement did is try to make it sound more marketable at the cost of oversimplification. First up, these aren’t really “no password” mechanisms. They’re closer to ssh certificates. You need to authenticate through some other mechanism and then agree to do the equivalent of creating and installing ssh certificates on your device. The ssh certificates get synchronized…
Hottake here: The biggest mistake that the passkeys movement did is try to make it sound more marketable at the cost of oversimplification. First up, these aren’t really “no password” mechanisms. They’re closer to ssh certificates. You need to authenticate through some other mechanism and then agree to do the equivalent of creating and installing ssh certificates on your device. The ssh certificates get synchronized…
what if you sign up a new account somewhere with a passkey? Then, it's the primary authentication method, right?
Consider a shared computer in a university laboratory or at a public library. Or maybe an iPad that is shared by a family.
As a service provider, you usually can not assume that someone using your service will log in with a dedicated device or with a device that has their primary google or apple accounts setup on it. (Some rare exceptions might exist).
I don’t think anyone wants to deal with customer support problems of “oh, I’m stuck in a different country when on a holiday and my phone got stolen, can you please recreate this key exchange process for me on this untrusted device logged in from public wifi at a coffee shop?”
Like with ssh certificates, you create more problems than you solve if you use passkeys as the primary authentication mechanism.
To answer your question, yes it would be primary authentication if you used it that way. But no sane person would. Hopefully.
Hottake here: The biggest mistake that the passkeys movement did is try to make it sound more marketable at the cost of oversimplification. First up, these aren’t really “no password” mechanisms. They’re closer to ssh certificates. You need to authenticate through some other mechanism and then agree to do the equivalent of creating and installing ssh certificates on your device. The ssh certificates get synchronized…
Maybe they could have used more marketable terms like "1-time password", or "barely a password", or "mini-password" (to denote minimal expected usage of your password), etc.?
It reflects that the mechanism is a way to securely store some identity related information. It is not a mechanism to establish that identity.
The value proposition is still obvious: You need to establish your identity once, and then you can securely save it and share it across devices and avoid having to reestablish your identity every time.
It also removes the “password” confusion entirely. Establishing identity could be through a fingerprint or verifying a government issued Id card in person etc.
The name also correctly reflects what it is doing while still sounding marketable to non technical users. The mental model that a non technical user will build more closely reflects what is actually happening - which is always helpful to build a good user experience.
Earlier quoted context omitted.
This is accurate, but by putting your passkey backup with that external entity, you are putting all your keys in that basket. Passwords have an obvious, backup option with zero dependencies on third-parties: A printed list in a fire safe. I would not advise users go heavily with any passkey provider that does not provide a physical backup of a similar form that can be secured through non-technical means, and that can…
Passkeys aren't inherently un-backup-able. I do agree though that the most common forms of it (e.g., Android/iOS/Windows secure enclave passkeys) need better ways of recovery and remediation. That said, what you describe is easily doable in other forms. For hardware tokens, you can have a spare Yubikey that's authorized on your accounts and keep that in a fire safe with its unlock PIN. For something like 1Password, y…
Agreed, I'm just not willing to endorse their use until there are robust recovery and remediation processes.
> For something like 1Password, you can print out a recovery kit [1] with the secret key and unlock password.
Yeah, this is what I want Google/Appleto provide as it is robust to both user incapacity and provider refusal-of-service.
Earlier quoted context omitted.
This is accurate, but by putting your passkey backup with that external entity, you are putting all your keys in that basket. Passwords have an obvious, backup option with zero dependencies on third-parties: A printed list in a fire safe. I would not advise users go heavily with any passkey provider that does not provide a physical backup of a similar form that can be secured through non-technical means, and that can…
The problem with that is people don't have fire safes. Or homes in some cases (e.g. many unhoused people have smartphones now). Also people need to travel and do recovery without having to fly home to their safe. The idea that printing a backup is easy and an option for many people is often not the case.
Fair enough, but that is an argument for multiple durable recovery and remediation solutions, which few of the current providers have.
Hmmm. I don't want to be dependent on any cloud provider for my logins. Any passkey solution must be fully self hosted for me to accept it. Is there such a thing yet?
The only annoying thing about this setup is having to manually add each key to each new passkey-enabled account I have.