> Passkeys work in Apple’s Safari web browser as well as on its devices.
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.
What is Apple doing wrong here? Surely it’s a case of Apple being first to implement a standard where other vendors – Firefox included – are expected to follow?
I don’t know what it means for the password managers, but I don't see that it stops you using those either.
I want to use my iCloud keychain as a password manager since the level of trust I've already given apple allows them to acquire most of my passwords (and 2 factor codes) anyway.
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.
> 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.
Google recently asked me to connect via Bluetooth to authorize my laptop with my phone. Just that Bluetooth was completely disabled from my laptop and it did not offer any other option.
For some reason the login on Gmail still offered the 'press ok on your phone' method. No idea what I should have done otherwise.
That would make it impossible to login to anything personal through a locked down device, like a corporate computer.
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.
But can the private key be exported or can I login only with the help from my Apple™ iPhone? What they describe isn't interoperability, it is 2FA using a phone. Interoperability means they implement a standard and I could migrate my key to an android phone. Is it the case?
It's based on Webauthn and other FIDO standards. Private keys can't be exported (because it would defeat some of the features of a "secure enclave"), but other keys can be added to keychains. You should be able to migrate between devices/device-types across the Webauthn and FIDO standards. It's still early days that some of that isn't easy or "complete" yet, but the standards are being built and Apple and Google and Microsoft have all agreed to cooperate on them.
I am not sure I understand the nuance between exporting a key and migrating the key between devices. Surely if you can do one you can do the other (at least technically/in term of security).
I don't currently know the specifics of the standards, but often key migration means signing and publicly announcing a new device's hardware public key and optionally revoking an older device's hardware public key. The private keys themselves might never leave the hardware secure enclaves (and/or other key escrow services) to do the dance of updating a keychain of public key signatures. The big "advances" in the standards over the last few years have been about moving away from the "classic" PGP/CA style PKI assumption that a user is represented by a single strong key and a hierarchy of owned subkeys and more that a user is represented by a keychain of N keys many more roughly "peers" than hierarchical and in something of a web of trust with each other where N is at least the number of devices the user owns and regularly uses, and often much more than that with various key escrow strategies. I believe the "PassKey" approach uses an escrowed sub-key per-website in many cases so the keychain gets conceptually huge. (Escrowed here is that it is a derived key using data available to some quorum of physical device keys. You can rederive escrowed keys, but you can't export physical device keys that made the escrow data in the first place. You should be able to add new device keys that can share in a quorum to get at that data, but it's a migration dance.)
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.
One thing I never understood about this passkeys thing is: how will the passkeys database be kept in sync between your iPhone, your Windows desktop, your Linux laptop and your Android tablet? I've tried to research the topic a bit but everything I've been able to find has been about exporting and importing between ecosystems, but most people don't use only a single company's products.
Apple has a long history of working best together with Apple. For example, the iPod music players only worked with iTunes. I think that Apple hopes that such features cause people to switch more of their electronics to Apple
Sure, but this is trying to replace passwords. As much as Apple would want it different, there's a whole lot of people who use one Apple device but has other devices from other manufacturers, and surely an industry effort like FIDO to replace passwords would take that into account?
> there's a whole lot of people who use one Apple device but has other devices from other manufacturers, and surely an industry effort like FIDO to replace passwords would take that into account?
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.
Apple made talking to family, friends and other people a moat to keep people in their walled garden. Taking control of your passwords is extension of that strategy, not something they feel bad about.
Uh, iPods could be used with plenty of third-party software, including WinAmp, foobar2000, MediaMonkey. I could go on for another several minutes rattling off names.
Right, but all software which uses passwords would need to support it too, right? I'm not confident that all of the Windows ecosystem will adopt iCloud for passkeys, nor am I confident that Apple will tightly integrate into whatever system thing Microsoft puts in Windows to manage FIDO keys... This isn't like a password manager after all, where getting the key in your clipboard is a universal way to use it anywhere you want.
Apple says they are working with Microsoft and Google to meet all FIDO standards on this. It's still early days, but FIDO as a standards body does seem to be working towards standards for working with heterogenous keychains. Given how many users use Chrome on Windows and have an iOS device, I think heterogenous keychains are going to be critical to mass adoption and everyone says they are working towards that. A lot of this may be on FIDO to truly coordinate.
The passkeys are only synced across Apple devices, via iCloud keychain. Trying to sign in on another device (e.g. Windows laptop, Android phone) will require scanning a QR code. The devices then establish a secure channel using FIDO caBLE v2 (introduced by Google/Chrome, I believe) to perform the authentication. This ensures the passkeys never leave your Apple device, but can still be used on other devices.
Aha, so you get a significantly worse experience if you're not 100% in the Apple ecosystem, and you can't sign in at all if you don't have your Apple device on you.
You can use password manager that is cross platform. You can even use something like KeePassXC and sync the database between devices. All encrypted and secure without even having a phone if you want. You don't need to remember passwords without or with your phone.
Presenting this as a choice between using Apple's closed solution or using easy-to-remember passwords is disingenuous. Please don't participate in the discussion if you're going to be this bad faith.
> Please don't participate in the discussion if you're going to be this bad faith.
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.
It's especially ironic given that what Apple has implemented is literally an existing web standard. Luckily web apps supporting WebAuthn should also be able to support alternative means of authentication so they don't break when you don't have your device with you.
I don’t see how an extra program built for windows or linux can in any way stall whatever project limits Apple faces for macos. They’re effectively independent projects.
There are only so many competent software developers and managers out there. Managers have limited bandwidth as well. For everything any organization says “yes” to, it’s saying “no” to something else. That’s true even if the organization has a huge cash pile.
I find not having to contend with the break-up of iTunes into a gazillion of separate apps (so far, fingers crossed) to actually be an advantage of using it on Windows these days.
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").
The CEO of Apple just publicly said something that contradicts your working experience. I'll trust him to clearly explain the strategy over your experience.
Apple product direction is set by execs who buy their entire extended family iPhones and switch between their three HomeKit-enabled houses and driving to work in their CarPlay cars. This biases how they determine value in things, beyond the obvious reasons.
As a person who isn't in the Apple ecosystem, this has always been what kept me off iOS.
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.
Does this passwordless future still involve getting a cookie in your browser that can be stolen and used from an attackers machine? If so, we still have a problem to fix.
Which websites support passwordless authentication (FIDO2 WebAuth)?
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.
Does anybody understand how passkeys protect against phishing more than OTP codes do? With OTP codes, an attacker can just ask the user to share their code ("please share your 2fa code to authenticate yourself"), surely with passkeys the same attacker could just ask the user to scan the login QR code ("please scan this QR code to authenticate yourself").
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...
FIDO authentication, of which webauthn is the successor, works like this: your secret is a signing key for a digital signature cryptosystem. When you authenticate, it signs a message containing various things including the hostname of the site being authenticated to, and because this is under the control of the browser, a phishing site can't fake it easily (also the browser will throw a fit if you're not on https).
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.
I was more worried about attacks where the attacker takes a screenshot of the QR code and sends it to the user while pretending to be a support agent. So the user never even opens any evil site in their browser.
Scanning a qr code triggers a bluetooth bridge to continue. If a scammer or your mom scans it from someplace else, it won’t work. Good for antiphishing. Bad for oops, left phone at home.
Well, if you can get the user to install malware on their computer ("you must update your flash plugin to continue ...") then you could potentially fiddle with their certificate store, or many other things.
Passkeys are designed to take away further control from you and that is why BigTech are promoting it. Do you really want to tie your digital life to a device?
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.
> There’s no shortage of security people who will tell you that passwords are broken. It’s also not a coincidence how many of them sell products to supplement or replace passwords. (Microsoft Ruined Passwords, Now Aims for a Passwordless Future: https://puri.sm/posts/microsoft-ruined-passwords-now-aims-fo... ).
Passwords can be reused and stored on remote servers, if one is compromised, those password are now out there. Passkeys are asymmetric so the actual key is only stored in your keychain and the UX basically prevents reuse
Thanks. I'm still not following 100%, though. Is the problem that some providers foolishly store users' passwords in clear text, or that some providers allow passwords whose hashes are easy to reverse?
Both, plus people reuse passwords for random websites that might be malignant, plus they share them through social attacks, plus they put them in Post-its, plus they use easily guessable or brute-forceable passwords…
The idea of authenticating is the presentation of your id, something only you know (a password), and potentially something only you have (2fac).
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).
We went from having one password used on most all sites to having unique random passwords for each site saved in a password manager. But of course those are all accessible then via a single , traditional memorable easy to type ‘single’ password. Yes requires access to one’s devices and helps avoid phishing and all other benefits but just interesting. With passkeys assuming one still uses a password manager to manage the keys (since otherwise if your devices were lost or stolen you’d be screwed) then all your passkeys are stil behind a regular memorable easy to type password and a computer password that is also by nature a memorable password, etc. There are again still lots of benefits for the new method and help avoid the most common issues for people currently so none of this is bad but more good to realize you still have a password in general just one to manage them all.
I feel we're powerless to stop this, since it's an extremely easy sell to normal users. The average iPhone user wouldn't think once, let alone twice, about clicking OK on that shiny new doodad-app, and that's all the critical mass they need.
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!
> Am I freaking out unnecessarily? Is my reasoning flawed?
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.
I'm not sure where this specific key is (in Apple's implementation), but WebAuthn doesn't care where the key lives. Mine is in a Yubikey, I think/hope that will work, if the implementation is "plain" WebAuthn.
I'm not sure either, but going on how Apple implementations that I _do_ know about, I'm going to go out on a limb and say it won't be something you can directly control, like a Yubikey.
I agree we won't be able to stop it, but on the up side I think that it will reach a critical mass and apple will get forced to make it interoperable with other platforms.
But between introduction of this feature anf it becoming Cross-Platform, years will go by...
> Passkey synchronization provides convenience and redundancy in case of loss of a single device. However, it's also important that passkeys be recoverable even in the event that all associated devices are lost. Passkeys can be recovered through iCloud keychain escrow, which is also protected against brute-force attacks, even by Apple.
> 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.
Oh, cool, Apple developed a new technology it calls "passkeys". I wonder how they work.
> 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
98 comments
[ 6.5 ms ] story [ 175 ms ] threadI 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.
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.
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.
Making your experience bad on non-Apple devices is part of the design, not accident.
They just have a million things they want to do, limited resources and so they simply don't prioritise it.
haha, oh really?
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.
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").
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.
iCloud still requires a mail / pass combination to access stored data.
Not sure if there is anything else in the works.
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.
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...
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.
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-...
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).
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...
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?
> 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.
> 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