51–60 of 421 posts
What happens if you lose your device or it breaks or something? Do you lose access to anything tied to it?
It's tied to a key stored in your iCloud. So basically as long as you have a device tied to your iCloud you can get in. Presumably, if you lose access to iCloud you will have problems.
Beta support for Passkey is already in the current macOS/iOS releases: https://developer.apple.com/documentation/authenticationserv... I am already using Passkeys on some websites.
Yes, it looks like it’s been around for a couple of months, after a somewhat quiet announcement. It’s the first I had heard of it though.
Earlier quoted context omitted.
As a long-time Safari user who uses keychain heavily in lieu of 1Password or other managers, I probably will migrate to using Passkey because it sounds pretty seamless. But the lock-in point seems like a founded critique. Does anyone disagree with this claim?
I'm not sure this is any more locked in then the parent post is locked into 1password. Moving auth tools is a pain. Anyone implementing FIDO should allow you to enrol multiple devices. As long as the auth consumers allow multiple keys, there's no lock-in. You just need to setup your new device before ditching apple.
Also, I imagine that many people do not have the luxury of multiple devices. So if you lose your phone, you'll need to buy or at least borrow another iOS device to recover it from iCloud before you could switch to Android.
The page doesn't state it explicitly; is this Apple's implementation for FIDO2?
The video presentation said it was part of the FIDO standard.
Earlier quoted context omitted.
I think Apple encrypts the pass keys locally on your device, then stores encrypted copies in iCloud, which you can download and decrypt on a new device. On the new device you would be prompted for the passcode of the device you lost or broke, to decrypt and access them.
iCloud (and anything on iCloud) is explicitly not encrypted, though [1]. [1] https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
It does mean that the data is not sitting in clear-text form on the provider's disks. But the exact details of that encryption may vary from provider to provider.
Does anyone know if this is different to Webauthn? You can already login with touchid/faceid, with the private key stored in apples keychain. Lots of sites support it, I just added it as 2FA to Mailpace ( https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ ), making it passwordless login instead of 2FA is trivial and fully supported by webauthn. What’s different about this?
So, if you have macOS or iOS software for Mailpace, this is a way to have the same workflow for that as you get with WebAuthn for the web site.
Android likewise has an API for apps to get this, as well as the Chrome browser on Android having WebAuthn, and if you have apps on both platforms it might make sense to do that there too.
Technology wise the key difference is that for WebAuthn the Relying Party ID - the thing that distinguishes GitHub from Facebook (for example) is based on a DNS name, and that's verified by your web browser, while for these app APIs the RPID is based on some platform identifier and is verified by the host OS.
So, GitHub won't get your Facebook credentials because github.com and facebook.com are different DNS names. Likewise "The 100% Legit Mailpace App" on iOS can't get the credentials for "Albert's Real Mailpace App" because they have some different internal iOS ID.
At the backend, validation is pretty similar except the RPID is different, and you'll need to read the documentation carefully to figure out what the RPID is for these app APIs, if you have a pile of magic numbers for "your" app it's probably one of those. You don't get to specify, because the whole point is that nobody can impersonate your app (well, obviously on an iPhone Apple could impersonate it, and on Android Google could)
Earlier quoted context omitted.
It's tied to a key stored in your iCloud. So basically as long as you have a device tied to your iCloud you can get in. Presumably, if you lose access to iCloud you will have problems.
Apple is the face on the screen. There is no lady with a hammer. https://youtu.be/OYecfV3ubP8
So your analogy makes absolutely no sense.
Earlier quoted context omitted.
If you can extract tokens from a device, then they're basically passwords, not tokens — i.e. anyone who can hack your device can get them. Tokens only add multi-factor security insofar as they have distinct exfiltration requirements from passwords. Services that properly support MFA should simply support accounts having multiple bound authenticator devices, each with their own private key/seed. In such setups, the pr…
Your first paragraph, restated, is that passwords are superior to tokens. Your "proper way" is absurd and nonsensical for the vast majority of users. The first time they get burned by this is the last time they'd rely on anything but the one memorized password they reuse everywhere.
The point of setting up MFA is to secure things that really need to be secure, where the person with the data is aware of real attacker threat-profiles that have real interest in their data. It's a thing that companies that hire CISOs care about.
Any implementation of MFA you see in the wild is either part of a product that has an enterprise tier that has customers like that, where the product devs decided to "trickle down" the feature [in a less-secure, but possibly optionally secure, form] to lower plan tiers; or it's a cargo-cult reimplementation where a company "saw other companies doing it and it seemed like a good idea" — but they exchanged actual security for convenience.
(You can usually distinguish one from the other, because the companies "actually doing MFA" will almost always support smart-card authenticators — and have for decades, back since doing so required a Java applet. Because "issuing each employee a smart card" is what companies that actually care about cybersecurity — e.g. defense contractors, investment banks, etc. — do as a matter of course.)