It sounds convenient, but I can just anticipate a situation where I don't have access to iCloud and be unable to check my email on a different computer. Just two weeks ago, I attempted to create an iCloud account for a family member and it was disabled (they were using my mac) - maybe it looked suspicious - IDK. Point is, that apple was able to completely lock us out of iCloud with no recourse, not even a phone call, an email, or a warning. No thanks.
My wife has an iPhone and no other Apple devices. When that phone got bricked and she couldn't remember her iCloud password, she was completely out of luck. Available recovery mechanisms were SMS or having another Apple device. Calls to Apple went nowhere and provided no options to recover.
If that device was the one source of her access to all of the accounts she has, she would have been completely unable to do anything until purchasing a new phone and porting her phone number to that phone.
>Passkeys use Touch ID or Face ID for biometric verification
I was under the impression it was very poor security to use something like a face or fingerprint as a password... Okay for a username, but should be avoided at all costs for passwords.
Interesting but in the Apple case you'd need a cast of your intended victims face or finger to even attempt this attack.
It's easy to use a mask (or occlusion) to prevent a system from detecting your real face, but spoofing a specific person's face is a much bigger task. Any decent modern face rec system is going to use liveness detection as part of its analysis.
At least for Apple's system, biometrics aren't used server-side. Biometrics are used to authenticate to the local system (e.g. your laptop or phone) and authorize use of a local private ECC key for further authentication to other services. The T2 secure enclave mediates all of this. The private ECC key never leaves the T2 chip. Biometric data is never stored unencrypted outside the T2, although like a password may be susceptible to capture when input. (The fingerprint scanner might be hooked up directly to the T2 chip, though, in which case attackers would need to resort to more direct methods for capturing fingerprints.)
Do you mean the private ECC key? I don't know the specific details of the system, such as if or when a specific device key used for iCloud enrollment can be rotated. (I have no specific familiarity with Apple's iCloud or device management code, I'm just familiar with publicly known details of the T2, and also familiar with the macOS/iPhone Keychain APIs for generating and using T2 keys.)
But in case it wasn't clear: it's not an API key, but a public/private ECC P-256 key pair used for ECDSA signing. Apple only knows the public key (it doesn't much matter if the whole world knows the public key), whereas the private key never leaves the T2 chip. If any secrets have been exfiltrated from the T2 enclave there are bigger problems at hand, and generating a new key pair would be useless before fixing those problems.
I feel this article is not quite clear about the whole process. The secret which I take in this case is the private key is supposed to reside in your phone's trusted platform module and to be completely inaccessible nor stored on a server, however it is possible to synchronise your keys through iCloud ?
Also what happens when you flash a Qr Code, is Apple involved at any point (which makes it a pretty big spof) ? Can Apple add/revoke login authorisations for individual devices, and if so is there really a fundamental difference between this and an Apple SSO with biometric checks ?
From a naïve point of view it resembles Github/lab/tea SSH key-based authentication with extra steps, a us-based third party cloud provider involved and a new sheen of consummate proprietarism
It’s PKI replacing shared secrets, with a user friendly UX. For the 900 million active iPhone users in the world, it’s a net positive, not to mention the 3 billion Android users who will also benefit from this open standard (as Google has also committed to supporting passwordless FIDO2/WebAuthN).
Credential stuffing, weak passwords, password database leaks, all solved for with passkeys and leveraging existing smartphone ecosystem security mechanisms. Over time, your casual user might not even need a password manager anymore: your mobile OS is the password manager.
I would like to understand how this new system handles the following issues:
1. Sharing accounts. If I want to share a subscription to the Economist with my wife, say, I give her the username/password. Does the Apple/Google/MS alternative support multiple authorised identities?
2. Single point of compromise -- if the identity system or the phone is compromised, everything is compromised.
3. What if the biometric doesn't work, or the biometric sensing system doesn't work. Say my phone camera has just stopped working (which it coincidentally has, as I write this) ... does it freeze me out?
> 1. Sharing accounts. If I want to share a subscription to the Economist with my wife, say, I give her the username/password. Does the Apple/Google/MS alternative support multiple authorised identities?
Each registration and subscription is for the personal use of the Registered User or subscriber only. You may not share your log-in details or password with any other person. You may not share or transfer your subscription.
https://www.economistgroup.com/terms-of-use
2. Most people already have a single point of compromise in their primary inbox, password manager, or browser storage. This doesn't solve the single point of compromise problem, and I'm not sure that any easy-to-use system could.
3. If the camera fails to recognise me currently when I use Apple Wallet, I am invited to enter a passcode. I'm not sure if this same fallback would be implemented, but I do see a photo which indicates that you can use an external security key instead of biometrics.
If the provider of the "green SMS bubble" stops selling data for a living, sure. I left Android a while ago for a reason. I loved Android; however, the privacy practices became too much for me to be comfortable with.
I mean I get it. I've read the GNU manifesto when it was fresh and nodded along.
But the adult thing is that 90% of the freedom to be had is outside of computers. The total calculus might very well give you more freedom if you go full Apple in 2022 compared to many of the other options.
I have chosen the freedom to get my objectives done and get on with my day. The Apple ecosystem is unrivaled in letting me do that, and I never see an ad or have my tracking data sold on a daily basis.
It’s a real bummer that despite having TLS client certificates available for years, public key user authentication that actually gets traction is going to be proprietary nonsense.
Turns out putting a quality interface with convenience and ease of use in front of people matters. Problem is so much PKI infrastructure is built for businesses and sys admins.
There was never anything stopping browser devs from putting a quality UX on client certs.
FIDO seems to always require JS these days, too. Sucks that we're headed to a place where you won't even be able to log in without executing arbitrary server-provided code.
