Apple’s Killing the Password. Here’s Everything You Need to Know
wired.com
wired.com
> iCloud Keychain escrows a user's keychain data with Apple without allowing Apple to read the passwords and other data it contains. The user's keychain is encrypted using a strong passcode, and the escrow service provides a copy of the keychain only if a strict set of conditions is met.
> To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode. iOS, iPadOS, and macOS allow only 10 attempts to authenticate. After several failed attempts, the record is locked and the user must call Apple Support to be granted more attempts. After the tenth failed attempt, the escrow record is destroyed.
> Optionally, a user can set up an account recovery contact to make sure that they always have access to their account, even if they forget their Apple ID password or device passcode.
https://support.apple.com/en-us/HT213305
This just looks like passwords with extra steps and making it harder for customers to leave Apple's ecosystem.
Making your experience bad on non-Apple devices is part of the design, not accident.
If I have an Android device, I can use Linux or Windows (or macOS for that matter) on my laptop/desktop. If I have an iOS device, not using macOS just doesn't make sense and the only way to get a macOS legally is buying Apple hardware.
When the Apple watch came out, I was interested to see what Apple brings to the space but my interest was killed when I realized it will for all intents and purposes be an iOS companion device, not a true standalone product. So buying an Apple watch would have meant replacing my phone with an iPhone, which would have meant replacing my laptop with a macbook and my Android tablet with an iPad.
On paper there's nothing stopping anyone from using iOS devices and keeping their desktop/laptop on Windows or Linux. But the path of least resistance is buying into the entire Apple ecosystem (including iCloud, iTunes, etc) and getting any non-Apple alternative to occupy any of the slots Apple provides its own options for is an uphill battle (e.g. even when Apple provided a Windows version of iTunes it was notoriously bad, slow and lagging behind).
This irks me not only because it means you'll want to replace every digital device and every app Apple provides a stock solution for, you'll also find it nearly impossible to leave because there's no clear migration path if you have come to rely on iCloud, Keynote, Facetime, iMessage, your Apple wallet, your Apple credit card, or even Apple maps. If you want to add any "foreign" device, it will instantly be a worse experience than if you had picked the Apple alternative. Instead you'd have to either go cold turkey or wean yourself off by using alternative cross-platform apps when available (and willingly accepting the worse experience).
I think there are plenty of disingenuous criticisms of Apple (especially about their devices being "overpriced" when they're really just "too expensive" compared to equivalent consumer products available with more affordable specs) but I think it's extremely fair to describe their practices as an extreme example of vendor lock-in.
They just have a million things they want to do, limited resources and so they simply don't prioritise it.
You can't just add unlimited developers to a project and expect it to be productive or sustainable.
No different at Meta, Spotify, Netflix etc.
Unless you care about interoperability, which for a product like this is essential.
haha, oh really?
That's because I prefer to manage my collection of radio comedy episodes as podcasts [1], and with unified iTunes that's simply a matter of changing the media type of those files to "Podcast" and voila, it just works. On a modern Mac on the other hand, from what I've gathered this is no longer possible, and the separate Podcasts app that has replaced iTunes in that regards only supports subscribing to "real" podcasts, and doesn't allow manually adding additional episodes. (I suppose I'd have to resort to either hacking the local podcast database, or set up a local HTTP server with a fake podcast feed in order to add those files, or just give up on that prospect entirely…)
[1] So they don't clutter up my actual music library, to get the listened/unlistened visual indicator, and due to way I'm syncing iTunes with my Android phone, to also get my phone to remember the playback position, too (in iTunes you can enable remembering the playback position for any file, including music tracks, but my Android media player nevertheless only supports this for files synced over as "podcasts").
You can see the sign-in user experience here, when they use a non-Apple device: https://developer.apple.com/videos/play/wwdc2022/10092/
I'll keep using passwords, thanks.
That works both ways. You've asked a question, to which the information is easily accessible online[https://support.apple.com/en-gb/HT213305]. It very clear from both the article and other online sources that this is based on WebAuthN[https://webauthn.guide]. You have been equally as disingenuous and based on your responses, acted in bad faith from the beginning in a bid to start a flamewar. How what you are doing is anything but basic bullying is beyond me.
My question was genuine. I have been trying to look into this before and not found anything on how keys are supposed to be synced across ecosystems. And your links don't explain that either; the Apple link explains how it syncs _within_ the iCloud ecosystem, not how it syncs between the different ecosystems. I didn't find your WebAuthN link before, but quickly skimming through it, I don't see anything about how keys are supposed to be synced between ecosystems. And when I have looked into this before, all I've been able to find is solutions to migrate between ecosystems, not syncing between them, which are wildly different use-cases.
If you have nothing productive to contribute, please don't.
> If you are using passwords THAT YOU CAN REMEMBER WITHOUT YOUR PHONE then I assume it's pretty basic and insecure.
> Presenting this as a choice between using Apple's closed solution or using EASY-TO-REMEMBER passwords is disingenuous.
All caps to indicate how sbuk changed the meaning of what mort96 said.
The dichotomy was between using using Apple's solution and using passwords. Deciding the latter must mean using easy to remember passwords and not acknowledging the existence of password managers and complex password generators is at best ignorance or forgetfulness and at worst dishonesty.
Unlike mort96, I didn't automatically assume dishonesty, but sbuk posted this in response to mort96's accusation:
> You have been equally as disingenuous and based on your responses, acted in bad faith from the beginning in a bid to start a flamewar. How what you are doing is anything but basic bullying is beyond me.
This implies that they were aware of what they were doing and, rather than call mort96 out on what they believed to be an attempt at a flamewar, decided to contribute to it by deliberately altering the meaning of mort96's message.
I believe mort96 and sbuk were both accusatory and rude, but what sbuk appears to have done would be worse in my view. Rather than just assume the worst of who I'm communicating with, I'd rather give them the benefit of the doubt by inquiring for more information, attempting to inform, or possibly explaining how I interpreted a passage.
They're not the beachhead. Once the product is tuned for core users, it can be expanded to more complex use cases. This is basic product development, and something Apple gets right.
No thanks, I'll stick to passwords associated with my own email.
Too many digital eggs in one digital basket. Losing access to stuff because some algorithm flags you for using a VPN is fucking stupidity.
Edit: I looked into it a bit more, it seems like it only works if the browser and scanning phone are in bluetooth range. That's definitely pretty good in terms of phishing protection, but a hard dependency on bluetooth would mean this will not work at all on many desktop computers...
The result is that if you are tricked into entering your credentials into google.com.totallynotaphishingsiteipromise.evilsite.com which is doing a man-in-the-middle attack against the real site - maybe with a let's encrypt cert so they can do https on their own domain name - then the authentication token they send to the real google will have the correct signature, but the wrong domain name.
So a domain hijacking attack is the only possibility? (and made drastically harder for serious websites with Certificate pinning)
https://www.digicert.com/blog/certificate-pinning-what-is-ce...
Microsoft and eBay, AFAIK. The rest may use U2F as a second factor not the only one.
Also, for recovery you need multiple phones, and you need the websites to support that. It will probably take a while for websites to support this, and even then people are not going to buy and register several phones.
Even if they _were_ to think twice, what are the feasible alternatives? A password manager where you generate passwords for each account? Sure, I do that, you probably do that, but good luck getting your grandma to do that.
This is all super-bad because once it becomes unavoidable, Apple controls _your_ access to everything digital. Apple. Let that sink in. This is the company that backed down on encryption when the FBI asked them to. The company that has stronger device lock-in than any you could imagine.
Am I freaking out unnecessarily? Is my reasoning flawed? Genuine question!
Yes, very much so. I don't know about Apple's thing specifically, but WebAuthn is decentralized and open.
Basically how it works is that you have a private key and use that to log in to a site, no other servers or anything else required. I don't know what Apple's implementation specifically has changed, but if it's based on WebAuthn, it can't be much.
Overall, though, if WebAuthn becomes more widespread through this, it's a huge win for everyone involved, as it's more secure than passwords, easier to use, faster, more usable, and more private.
But between introduction of this feature anf it becoming Cross-Platform, years will go by...
From a usability perspective, Apple's approach is great. From a privacy rights perspective... it's very bad.
It has been proven that big tech firms are in bed with govs, and allow them to violate citizen's rights at their convenience. Is it a good idea to trust them with all your data, accounts, etc? Hell, no.
Already true for many people.
There will be passwordless alternatives given that BitWarden is investing in the tech[1] .
[1] https://bitwarden.com/blog/accelerating-value-for-bitwarden-...
> Under the hood, Apple’s passkeys are based on the Web Authentication API (WebAuthn), which was developed by the FIDO Alliance and World Wide Web Consortium (WC3).
Okay, so Apple didn't develop it.
It's good to see Apple getting on board with web standards like WebAuthn considering how much they are dragging their heels on web standards on iOS but I just wish we could stop reporting on them without framing everything they do as groundbreaking innovation just because a man in a turtleneck sweater would have said so.
Alternative headline:
Apple brings WebAuthn support to iOS 16 and macOS Ventura
And Apple syncs your private keys between your devices via iCloud?
Or for each account creates a new key pair for each device... based on your iCloud ID?
Passwords have a significant number of problems, the largest one is password re-use, so if your LinkedIn password gets stolen, it might be tried on your e-mail or bank account. The second is that they are hard to generate and then remember or store. This results in short passwords, easy to remember and therefore non random passwords, or written down passwords. Passwords can often be guessed. Passwords are easily forgotten, requiring complex, vulnerable password reset flows or interactions with fallible customer service reps. There are often policies that require inconvenient password resets where the old one is no longer valid. Passwords do not have attached metadata, so you might enter in a password on a website that looks like paypal, but isn't paypal. It's much easier to phish a password. Passwords can also sit on your clipboard after ctrl+c, which might be vulnerable. Passwords less than 9 characters can be brute forced and even passwords less than 12 characters might be vulnerable to state actors, especially if they aren't completely random.
There is an additional nuance between signing something compared to copying something that results in where data that can compromise you exists in memory. Sending a string to a root owned process and getting a signed string back is a bit different than asking a root owned process for a privileged piece of information (a password) and having that copied into your processes memory.
Pass keys mainly attempt to remove a significant amount of the human factor above (remembering, re-use, reset flows, etc.) while increasing overall convenience without sacrificing security.
Rather than providing the current tuple(id, something only you know, something only you have), the idea is you provide (id, something only you are or something only you know, something only you have). Something you are is face or finger id, and the fallback is something you know, which is your pin. Because keys are more or less universally unique and they can be stored in apples secure enclave or in privileged memory they can also work as something you have. If you run something that turns a QR code into raw text, you will find that 2 factor codes are more or less a private key that is saved into an authentication app on a particular device (iirc).
Not sure if there is anything else in the works.
I sure wish apple would be a little bit better of a citizen when it comes to interoperability. Safari only features (which is what I'm assuming this will be based on apples history and the quote) are upsetting. uBlock is the single most important piece of software on my computer and my devotion to it exceeds any and all possible other features.
I would very much like to stop moving from password manager to password manager after they take VC money to corrupt their trust model so they can make money.
From the article:
> Because Apple developed its passkeys based on the FIDO Alliance standards, the passkeys can work across devices and on the web. If you try to log in to one of your accounts on a Windows machine, you’ll have to use a slightly different method since your passkeys won’t be stored on that machine. (If they are saved in an external password manager, you would need to log in to that first).
> Instead, when you log in to a website in Google Chrome, for example, you will have to use a QR code and your iPhone to help you sign in. The QR code contains a URL that includes single-use encryption keys. Once scanned, your phone and the computer are able to communicate using an end-to-end encrypted network via Bluetooth and share information.
I suppose that's not the worst workaround, and the local exchange is pretty clever, but it sure would be nice if this would work with Firefox out of the box.
I don’t know what it means for the password managers, but I don't see that it stops you using those either.
Safari integrates with it, but there is no Firefox or chrome plugin to do domain based validation or to keep my clipboard sane.
Apple has either failed to allow uBlock to function in safari (after which I would consider migrating to safari), failed to write the Firefox integration plugin, or failed to create an API that would allow a third party to build a plugin. While apple can certainly choose to do/not do those things, it is not a happy customer experience.
That's Chrome's and Firefox' fault for not using the password autofill APIs: https://developer.apple.com/documentation/security/password_...
Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=117006...
Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1650212
Btw, Chrome used to be able to read from Apple Keychain, but they removed that functionality years ago.
Use the free and open source one?
For some reason the login on Gmail still offered the 'press ok on your phone' method. No idea what I should have done otherwise.
I like the SQRL approach better where the QR code you scan is a url that the phone will connect to directly to do challenge response. That works with any existing browser and computer, whatever the OS or level of locking.
[edit] reading other comments, I realised it is necessary to prevent a mitm attack, the iphone needs to have a way somehow to verify the domain from which the QR code has been served.
To my knowledge Keybase's breakdowns of how their keychain worked, including subkey escrow and key exchanges are still some of the easiest to read on the subject of how the math works, though I don't think Keybase's "standards" entirely resemble some of the details of the final standards from FIDO, but again I also don't know enough of the specifics of FIDO's standards as I'd like.
iCloud still requires a mail / pass combination to access stored data.