Why Passkeys Will Be Simpler and More Secure Than Passwords
Apple has unveiled its version of passkeys, an industry-standard replacement for passwords that offers more security and protection against hijacking while simultaneously being far simpler in nearly every respect.
You never type or manage the contents of a passkey, which is generated when you upgrade a particular website account from a password-only or password and two-factor authentication login. Passkeys overcome numerous notable weaknesses with passwords:
- Each passkey is unique—always.
- Every passkey is generated on your device, and the secret portion of it never leaves your device during a login. (You can securely sync your passkeys across devices or share them with others.)
- Because passkeys are created using a strong encryption algorithm, you don’t have to worry about a “weak” password that could be guessed or cracked.
- A website can’t leak your authentication credentials because sites store only the public component of the passkey that corresponds to your login, not the secret part that lets you validate your identity.
- An attacker can’t phish a passkey from you because a passkey only presents itself at a legitimately associated website.
- Passkeys never need to change because they can’t be stolen.
- Passkeys don’t require two-factor authentication because they incorporate two different factors as part of their nature.
After a test run with developers over the last year, Apple has built passkey support into iOS 16, iPadOS 16, macOS 13 Ventura, and watchOS 9, slated for release in September or October of this year. These operating systems will store passkeys just as they do passwords and other entries in the user keychain, protected by a device password or passcode, Touch ID, or Face ID. Passkeys will also sync securely among your devices using iCloud Keychain, which employs end-to-end encryption—Apple never has access to passkeys or other iCloud Keychain data.
Best of all, perhaps, is that Apple built passkeys on top of a broadly supported industry standard, the W3C Web Authentication API or WebAuthn, created by the World Wide Web Consortium and the FIDO Alliance, a group that has spent years developing approaches to reduce the effectiveness of phishing, eliminate hijacking, and increase authentication simplicity for users. Apple, Amazon, Google, Meta (Facebook), and Microsoft are all FIDO board members, as are major financial institutions, credit card networks, and chip and hardware firms.
Many websites and operating systems already support WebAuthn via a hardware key like the popular ones made by Yubico. You visit a website, choose to log in using a security key, insert or tap a button on the hardware key, and the browser, operating system, and hardware key all talk together to complete the login. A passkey migrates the function of that hardware key directly into the operating system—no extra hardware required. Websites that already support hardware-based WebAuthn should be able to support passkeys with little to no effort, according to Apple.
Before we get started, note that Apple writes “passkey” in lowercase, an attempt to get us to use it alongside password, passcode, and passphrase as a common concept. Google, Microsoft, and other companies will offer compatible technology and may also opt for the generic passkey name. While new terminology can cause confusion, “passkey” is better than the more technically descriptive “multi-device FIDO credentials,” which doesn’t exactly roll off the tongue.
Let’s dig in to how passkeys work.
Passkeys Bring the Benefits of Public-Key Cryptography to Everyday Logins
Passkeys rely on public-key cryptography, something we’ve been writing about at TidBITS for nearly 30 years. With public-key cryptography, an encryption algorithm generates a secret that’s broken into two pieces: a private key, which you must never disclose, and a public key, which you can share in any fashion without risk of exposing the private key. Public-key cryptography underpins secure Web, email, and terminal connections; iMessage; and many other standards and services.
Anyone with a person’s public key can use it to encrypt a message that only the party who possesses the private key can decrypt. The party who has the private key can also perform a complementary operation: they can “sign” a message with the private key that effectively states, “I validate that I sent this message.” Crucially, anyone with the public key can confirm that only the private key’s possessor could have created that signature.
A passkey is a public/private key pair associated with some metadata, such as the website domain for which it was created. With a passkey, the private key never leaves the device on which it was generated to validate a login, while a website holds only the corresponding public key, stored as part of the user’s account.
To use a passkey, the first step is to enroll at a website or in an app. You’re likely familiar with this process from any time you signed up for two-factor authentication at a site: you log in with existing credentials, enable 2FA, receive a text message or scan a QR code into an authentication app or your keychain (in iOS 15, iPadOS 15, and Safari 15 for macOS), and then verify your receipt.
With a passkey, the process is different. When you log in to a website offering passkey authentication, you will have an option to upgrade it to a passkey in your account’s security or password section. The website first generates a registration message that Apple’s operating systems will interpret—it happens at a layer you never see. In response, your device creates the public/private key pair, stores it securely and locally, and transmits the public key to the website. The site can then optionally issue a challenge for it and your device can present it to confirm the enrollment.
On subsequent visits, when you’re presented with a login, your iPhone or iPad will show the passkey entry in the QuickType bar and Safari in macOS will show it as a pop-up menu. In both cases, that’s just like passwords and verification codes today. As with those login aids, you’ll validate the use of your passkey with Touch ID, Face ID, or your device passcode, depending on your settings.
Behind the scenes, your request to login via a passkey causes the site server to generate a “challenge” request using the stored public key. Your device then has to build a response using your stored private key. Because you initiate a passkey login by validating your identity, your device has access to your passkey’s private key when the challenge request comes in and can respond to the challenge without another authentication step. The server validates your device’s response against your stored public key, ensuring that you are authorized for access. If it all checks out, the website logs you in.
A passkey replaces two-factor authentication, and it’s worth breaking down why, as it seems counter-intuitive: how can a single code held on a device provide distinct aspects of confirmation? The rubric for multiple security factors is usually stated as at least two of “something you know, something you have, or something you are.” A passkey incorporates at least two of those:
- Something you know: While commonly thought of as a password, the “know” part is really any fixed piece of information you possess. Think of a 20-character randomly generated password stored in your password manager. Do you “know” that? Yes, in the sense that it’s retrievable exactly as entered.
- Something you have: Because passkeys are locked to devices, you prove your possession of a device by unlocking the passkey: no device, no passkey.
- Something you are: Although passkeys don’t require biometric authentication using Face ID or Touch ID, it’s an option. Apple always lets you use a device passcode to backstop Face ID or Touch ID, so it’s a blurred line with “something you know” compared to a dedicated biometric device with no fallback option.
Think for a moment about the advantages here. A passkey:
- Resists phishing: As with passwords and verification codes, your device will only present a passkey in QuickType or as a pop-up menu option when on a website’s specific domain associated with the passkey. An attacker can’t fool you into entering a passkey on a deceptive site, as can be done with a password.
- Prevents reuse of a stolen key on other accounts: Because each passkey is unique to its associated website, even if the site suffers a security breach, the only credential that can be stolen is your public key. That public key is useless to help a thief log in as you at another site as they lack your private key to answer the login challenge.
- Blocks guessing, identity searching, brute force: Because every passkey has a super-complex secret, an attacker can’t successfully guess or brute force your access to a site.
- Eliminates 2FA hijacking: Because passkeys don’t have a second factor, they aren’t vulnerable to SMS hijacking and interception, site impersonation and phishing, and other techniques to acquire a second factor.
Apple stores each passkey as just another entry in your keychain. If you have iCloud Keychain enabled, the passkeys sync across all your devices. (iCloud Keychain requires two-factor authentication enabled on your Apple ID; Apple hasn’t said if passkeys will replace its internal use of 2FA for its user accounts.)
You can share a passkey with someone else using AirDrop. This means you have to be in proximity to the other person, another element in security. The details are shared through end-to-end encryption, allowing the private key and other data to be passed without risk of interception. Apple hasn’t provided much more detail than that AirDrop sharing is an option, so there may be other provisos or security layers.
Because passkeys replace passwords and a second factor, you may be reasonably worried at this point about losing access to your passkeys if you’re locked out of your Apple ID account or lose all your registered devices. Apple has several processes in place for recovering Apple ID account access and broad swaths of iCloud-synced data. For an Apple ID account, you can use Apple’s account recovery process or an account Recovery Key. For iCloud data, if you’ve enabled the friends-and-family recovery system, iCloud Data Recovery Service, you can use that to re-enable access. After you recover account access, Apple has an additional set of steps that enable you to retrieve iCloud Keychain entries: it involves sending a code via SMS to a registered phone number and entering a device passcode for one of the devices in your iCloud-synced set.
This is all a fabulous reduction in the potential for successful attacks against your Internet-accessible accounts. But there’s more: Apple isn’t building yet another walled garden. Instead, passkeys are part of a broad industry effort with which Apple says its implementation will be compatible.
Passkeys Are an Industry Standard, Not a Proprietary Technology
Apple built its passkey support on top of the previously mentioned WebAuthn standard, which describes the server side of how to implement a Web-based login with public-key cryptography. FIDO created standards for the client side of that equation and calls the combination of its protocol and WebAuthn FIDO2. Apple developed its own client-side approach that’s compatible with standard WebAuthn servers and should be interchangeable with other companies’ rollouts of passkeys. Google, Microsoft, and Apple made a joint announcement in May 2022 committing to this approach, too.
In Apple’s passkey introduction video for developers, engineer Garrett Davidson emphasized Apple’s commitment to compatibility, saying:
We’ve been working with other platform vendors within the FIDO Alliance to make sure that passkey implementations are compatible cross-platform and can work on as many devices as possible.
He then demonstrated using a passkey on an Apple device to log in to a website on a PC, showing how a QR code could be used to enable a passkey login to one of your accounts on a device or browser that’s not connected to your existing devices or ecosystem.
Here’s how you might log in to a passkey-enabled account on someone else’s PC using your iPhone with your passkey as the authenticator. During the login, you can opt to add a device instead of entering a passkey or other authentication in the browser. The website’s server generates a QR code that includes a pair of single-use passwords—they’re generated just for that login and used in the next step for additional validation. (Note that the device with the browser could be any passkey-supporting operating system and device. The authenticating devices might be limited by Apple or other companies to a smaller set, much like you can only use an iPhone to confirm Apple Pay in Safari on a Mac, not a Mac with Touch ID to confirm Apple Pay from an iPhone.)
The PC in our example also starts broadcasting a Bluetooth message that contains the information needed to connect and authenticate directly with the server. Scan that QR code on your iPhone, and the iPhone uses an end-to-end encrypted protocol to create a tunnel with the PC’s Web browser using the keys shown in the QR code. (This encrypted connection isn’t part of the Bluetooth protocol, by the way, but data tunneled over Bluetooth; Bluetooth doesn’t incorporate the necessary encryption strength.)
This Bluetooth connection provides additional security and verification by offering out-of-band elements, or details that the PC isn’t presenting to the device that’s providing authentication—here, your iPhone. Because Web pages can be spoofed for phishing attacks, the Bluetooth connection provides a device-to-device backchannel for key details:
- Server addresses: The QR code doesn’t tell the iPhone what server (or list of servers) it can connect to for the actual passkey connection. That prevents a browser from providing malicious information.
- Key validation: The successful creation of an end-to-end encrypted two-way session over Bluetooth using the keys in the QR code enables the iPhone and PC to confirm that the QR code the browser delivered and the iPhone scanned are identical. (Apple hasn’t yet provided full details on this stage. The operating system clearly generates the QR code based on a request from the browser, and the browser can’t sniff the Bluetooth connection. So a front-end attack that displayed a malicious QR code wouldn’t work, as the PC and iPhone communicate without the browser in the loop.)
- Proximity: Connecting over short-range Bluetooth demonstrates, with confidence, that the PC and iPhone are near each other.
This broad device and platform compatibility lets you maintain the same degree of passkey security and simplicity without downgrading to a weaker method for login when accessing your account using other people’s devices. Whenever there’s a way to force a weaker login method, malicious parties will exploit that via phishing, social engineering, or other interception techniques. (Providing a second factor via an SMS text message versus a verification code is a prime example of a weaker backup approach that has been exploited.) In fact, until passkeys can be used exclusively, password-based logins will have to remain available, and they’ll remain vulnerable.
There might be some usability hiccups as passkeys roll out, but they shouldn’t be widespread. It’s possible, for instance, that some WebAuthn server components will need to be updated or that Apple will have to add more edge cases to its framework to encompass how things work in the wild.
But imagine a world in which you can securely log in to websites using any current browser on any device running any modern operating system, without having to create, remember, type, and protect passwords. It’s relaxing just to think about.
The main question that remains unanswered is how portable passkeys will be among ecosystems: can I use iOS and Android and Windows and share a passkey generated on one among all three? Given that Apple has built an AirDrop-sharing method for passkeys, I hope FIDO’s broad compatibility includes sharing passkeys among operating systems, too.
A Return to Security through Proximity
Passwords have provided an uneasy security compromise since their introduction decades ago when multi-user computing systems began to require protection. Passwords are patently imperfect, a relic of an age when physical proximity provided the first level of protection, something rendered moot by the Internet.
In an effort to answer some of the weaknesses in a password system, two-factor authentication was grafted on to require that you had something besides a password, something that required holding or being near an object to validate your right to log into a computer, service, or website. But because 2FA starts with an account password and uses a second method that can be subject to compromise or phishing, it remains a patch applied to a damaged wall.
The passkey is a modern replacement for passwords that rebuilds the security wall protecting standard account logins. Proximity—in the form of the device that stores your passkeys—is a powerful tool in reducing account hijacking and interception. Passkeys may seem scary and revolutionary, but they’re actually safer and, in some ways, a bit old-fashioned: they’re a bit of a throwback to a time when having access to a terminal provided proof you were authorized to use it.
“Apple has built passkey support into iOS 16, iPadOS 16, macOS 13 Ventura, and watchOS 9, slated for release in September or October of this year.”
Two of my Apple devices are not going to be further upgradeable come this fall. At this point I’m assuming that any passkeys I might have will not be very “portable.” True?
Agreed. The other question I have is whether Apple’s system will be cross-browser. Apple will certainly have tight integration with Safari, but what about those of us who prefer to browse with Chrome, Firefox, Edge or other popular non-Apple browsers?
Will there be a macOS API so browsers can use passkeys managed by the system? Or will each browser manufacturer include its own FIDO implementation? And if it’s the latter, will this means that each browser will need a separate registration with web sites?
I’m hoping that Apple designs a common API for passkeys so browsers from all vendors can share the same set. Presumably, no browser (not even Safari) should be allowed to actually read the key, since that would allow a compromised app to exfiltrate the data, but they can probably use an API where apps can send in content to be encrypted/decrypted/signed/validated without actually seeing the key.
A passkey is supplementary to other authentication. So each website will make its own decisions, but on one that accept passkeys, you should probably also be able to:
It’s possible if you upgrade to a passkey, a website will only allow fallback to WebAuthn or 2FA, though.
You may be able to relay logins via an iPhone or iPad running iOS 16 on a device that is a version or more behind, too. Remains to be seen how that works.
Great question. I suspect Safari only for direct OS integration, but Google will probably allow passkey integration across the Chrome browser, Android, and ChromeOS if the right pieces are in place for secure local public-key storage on device.
Right now, Apple doesn’t allow the presentation of the Passwords login items within other browsers, although apps can allow a login to the app only using Passwords entries. By that logic, passkeys would be locked to Safari for generic website logins. However, Apple’s commitment to supporting an industry standard they helped form may result in a different choice with passkeys.
Will this “passkey” system be mandatory in iOS 16, WatchOS 9, etc ? Will I still be able to use the passwords I already use in iOS 15 on my iPhone & iPad Mini since I go to the same software/places (such as Apple’s Mail.app) on my 2011 iMac and 2011 MacBook Air which are limited to Mac OS 10.13.6, and my 2015 MacBook Pro which I believe will not go higher than MacOS 15.x
Or will the “passkey” just be used to log into the hardware only?
No, it’s an option for websites to implement for logins. I’m not clear if any apps would do the same—it requires a WebAuthn server on the other end and conceivably some apps could authenticate through it?
However, it’s not mandatory, doesn’t affect IMAP/POP/SMTP, and isn’t related to device passcodes for unlocking your hardware.
Nothing to do with that at all. A passkey is an operating system’s method of create a secure login for a website in which the private part of a pair of encryption keys is stored only on the device or synced securely among your devices:
Put another way:
Holy smoke. What an incredibly well-written informative article about a complex but important topic. I nominate for Pulitzer. Or a DogCow at least. Moof!
I’m thinking, yup. Anything else just wouldn’t be Apple. “This won’t be a walled garden. This won’t be a walled garden! This WON’T be a walled garden. BTW, MacOS will only support it in Safari.”
Things are interoperable, or they’re not. They can’t be both.
If Chrome, FireFox, and Safari each have separate keystores, this is going to be a big mess. How many people honestly never change browsers? I must switch every couple of months to a year and it’s already a hassle, plus I have maybe 5 computers I use regularly and I’ve found syncing between even separate instances of the same kind of browser to be often hinky, and that’s assuming you trust the idea of being locked into centralized services… the amount of spam I get to email addresses I’ve given out only once each, to major communications service providers who presumably have industry standard security, leads me to have a hard time trusting my most private authentication information to 3rd party servers. And, hopping from device to device, I’ve found even networked password managers too inconvenient to use, so I don’t know how a similar system is going to work when it’s 256-character cryptographic keys instead of passwords.
As to the Chrome/Android ecosystem, personally, I’m trying to divorce Google completely. Nuff said. They’ve still got my email going through their servers, but that’s it, and that won’t be for much longer.
The idea of passkeys is great. If we lived in a world where the corporations that make our hardware and software had a business interest in making tools to serve our needs, rather than their own, and built for interoperability instead of trying to rope us into proprietary software and “Embrace, Extend, Extinguish” schemes, I’d welcome this smart solution to the obvious drawbacks of passwords.
But here in the real world? Maybe the Linux folks will get a good implementation of this, at least…
I hate to be a pessimist, but I can’t pretend Apple’s direction over the past 15 or 20 years is something other than what it has been. Ever since Steve Jobs told the guys at Panic, “You guys are a little pushcart on the tracks and we’re a great big locomotive about to run you down”, I’ve noticed a lot more effort to try to control the uses of their products, and rope people into exclusively using Apple apps and devices, than to provide real flexibility and interoperability that might encourage an independent ecosystem of third-party products and services.
I’ve been reading all the posts about Passkeys and come across the acronym FIDO. I keep thinking DOG!
Please educate me —what does FIDO stand for? And now I see FIDO2!
Fast IDentity Online.
I can’t believe that there won’t be a solution to this. But, until there is, I believe the was FIDO is designed so that you have one device that knows your identity and contains all of your passkeys (for almost everyone, an iOS or Android smartphone.) Yes, Apple will sync passkeys to other devices with the same Apple ID using the same iCloud Keychain syncing that we use today, and Google will do the same between Android and Chrome browsers signed in to the same Google account. But on a browser where you are attempting to log in to a system using FIDO for the first time, where the pass key has not already synced, the web site will do something like show a QR code, your unlocked smartphone will scan the code, authenticate with the server, then the server will allow the browser to download the unique private key, so it will be on the browser (something besides Safari on a Mac, something besides Chrome if you own an Android phone) going forward.
The biggest issue is how do you switch from an iOS to an Android phone, or vice versa? Especially if you no longer have the old device (lost, stolen, broken, etc.) Apple and Google cooperated on the COVID-19 exposure notification system - I believe that they will come up with a joint solution of some sort that will allow these private keys to move end to end encrypted somehow between their platforms.
It’s not just switching. It’s syncing the data stores between them. I own both an iPhone and an Android phone. And I use computers running macOS, Linux and Windows.
With cross-platform password managers (e.g. 1Password or the password managers built-in to many popular web browsers), your passwords can be seamlessly sync’ed between devices. Will there be a way to securely do this for your passkeys? Right now, it’s anybody’s guess.
Maybe 1Password will add passkey support (using their own key storage if they can’t access Apple’s), and provide cross-platform support that way, but again, there’s no way to know at this time.
And there’s still the issue of cross-browser compatibility. For instance, I use Firefox almost exclusively on my desktop/laptop computers, but I run Safari on my iOS devices. Apple may sync the passkeys (via iCloud keychain) between my devices, but if the non-Safari browsers can’t use them, then it’s of little use to me.
I’m not one to slam a new product because of random speculation, but I believe the ability to easily migrate passkeys between different operating systems and apps is a critical feature that will need to be addressed in order to gain wide adoption of this tech.
With passwords, you can always manually migrate your data if you need to (you can just write them down, if nothing else works for you). But with a cache of cryptographic private keys, that won’t be an option for most of us.
I know that the FIDO people are working on this problem, but I don’t think we know when a standard will be released and how long it will be until OS and browser makers (especially Apple, Microsoft and Google) get on-board to support that standard.
Like with Wi-Fi, it sort of stands for nothing, even though it has the ostensible definition provided above. FIDO Alliance is the group of companies, and some of the standards are also labeled FIDO, but it’s more branding? Like “FIDO2” bundles the W3C Web Authentication API (WebAuthn) and FIDO’s in-house Client-to-Authenticator Protocol (CTAP). Wi-Fi 6, similarly, is 802.11ax plus a bunch of other 802.11 and other specs wrapped into an easy-to-say moniker.
This is a big improvement over the current system in which you need to bring up a password on your device and then painstakingly type it in, with all the concerns about password phishing, someone seeing your password, and just typing a unique, strong password into a browser while sometimes balancing a phone!
Apple hints at this in the presentation. Adam and I had a whole behind-the-scenes discussion, as he initially assumed passkeys required Secure Enclave. But I dug through what’s available, and I realize it cannot, because the passkeys can be shared. If it were a one-way encryption storage house, like with your device password, you wouldn’t be able to share the private key portion of a passkey.
Thus, passkeys are much more like passwords managed by the Passwords feature across iOS, iPadOS, and Safari 15 or macOS 12. As part of compatibility, I’m going to wonder if you’ll be able to export securely your entire set of passkeys to import onto another platform? Huge security issue: if you can export your passkeys in quantity (like 100s or more), that’s a bigger risk than a one-at-a-time export. So we’ll see how that gets finessed.
Most people live in single ecosystems for hardware, but not for software, so I agree, since this is a web-oriented solution, not a device-oriented one for logins. So if I use Chrome on a Mac and I’m all in for Apple, I still have a passkey problem. Likewise, if I use Windows at work, have an Android smartphone, and a Mac at home—much worse.
One question that I don’t see addressed anywhere is how passkeys will affect a Mac user’s ability to help another Mac user remotely. I offer tech support to several family members and to clients, and most of the time I help them out remotely. They trust me enough to share their passwords with me, but I don’t have the “proximity” advantage that comes with being next to them when trying to help them out. I guess we’ll see how this plays out in the years to come.
Tell me which part concerns you? This won’t affect logging into or remotely accessing a Mac, and websites clearly won’t abandon passwords for a long time to come—some sites will probably offer a way to opt into making passkeys your primary login method with additional protections if you need to use a backup method. But for people who already are daunted by using the Internet, etc., their accounts will probably remain password-only or password-plus-second-factor for many, many years.
Oh yes, I am not worried about the immediate future. And I didn’t mean to suggest that I was “concerned” — just curious about how this change will affect remote tech support.
I am just basically wondering about how this might play out. It could very well be that things will be easier. For instance, I have a client who’s almost blind and getting him to type passwords correctly (when I cannot type them for him remotely) can be pretty challenging at times. I can easily imagine having to set Face ID for him once and then using that and passkeys to avoid having to deal with passwords altogether.
We’ll see, I guess. Thanks for the article.
So, again I put that part in my post you replied to above. When you encounter a web site that you’ve not authenticated with before in Firefox, presumably the web site will show a QR code, you will unlock your phone, use its camera to get the QR code. If you have a passkey, it will let the server know, and then the passkey will get added to Firefox’s passkey store for use from that point forward, and Firefox will likely have its own passkey sync service to sync with other devices on which you use Firefox, as FF does now with passwords. Or perhaps MacOS will have a way to capture using a key combo to authenticate using the Mac’s keychain itself. Or both.
It’s also possible (likely?) that Apple will offer an API that will allow signed third party apps like Firefox, Chrome, the Kindle app for MacOS, etc., to access passkeys stored on your Mac.
We don’t know for sure yet. Passkeys aren’t even implemented yet (well, actually I think that Apple is already using passkeys when you try to log in to Apple ID online, as I know when I try it allows me to authenticate using my user account passphrase, and sometimes even my Apple Watch with a double-click of its side button - but I’m not really sure if that’s FIDO2), and it’s likely that they will be available only for a few web sites and services at first, and those services likely will still offer typical userid/password at the same time, and likely for quite a while.
That’s not what I believe happens. If you review the video, the QR code allows an iPhone to authenticate for a session (add a new device as an authenticator), but it does not create a method for new enrollment by the website with a passkey.
From the video:
I just had confirmed on Twitter by a Microsoft person involved in this effort that passkeys will be ecosystem unique, too—that bodes poorly right now for syncing or coordinating among devices or browsers not in the same ecosystem, but this is the first generation rollout of this technology.
If you need a way to use a passkey-like element across browsers and operating systems, get a FIDO2-compatible hardware key from Yubico. Broadly supported. If you work entirely inside Apple’s ecosystem (devices and Safari) with occasional non-Safari logins on your own or other devices, an Apple-managed passkey should work very well.
The FIDO alliance FAQ does say this:
So, I had that wrong about the private key being loaded to the computer using a “foreign” browser from a phone, but I knew there was a way planned for this. Not what I said, but they know it’s an issue to solve.
Right, that’s “credential usage”—sort of like an authenticator app for 2FA, except vastly more secure because of the steps taking to require a uniquely signed response that can’t be intercepted. (Phishing allows interception of someone entering a second factor from an authentication app, for instance, but phishing can’t intercept the browser-based credential usage described in your quote.)
When I tested Apple’s passkey demo site (https://apple-passkey.demo.hanko.io/), it worked with Chrome and Edge on my Windows PC, as well as Safari on my Mac and iPad. All I had to do was scan the QR code with my iPhone and I was off to the races.
I’ve idly watched the standards behind passkey evolve, and have not gone deep into them. Nonetheless, I could never shake the notion they seemed like a solution by enterprise/techbros intended for enterprise/techbros, with a large number of pain points and attack vectors for consumers. If any company could build a workable consumer solution on that, it might be Apple.
For the Apple ecosystem, are the following requirements correct?
If that’s roughly accurate, a significant number of Apple customers are excluded by default, and I can think of several impediments to consumer adoption in addition to a number of security/privacy concerns.
There are also barriers to adoption to site/service operators of less-than-enterprise scale. Say TidBITS wanted to support passkeys: how would that happen? The answer is probably a third party service and the complications/compromises those involve.
It’s possible passkey may develop into a useful technology that’s accessible, secure, and easy for consumer to use, and straightforward for sites/services to support. But I suspect we’re quite a long way from that. Until then (I’ll be blunt) it’s probably going to be a niche service limited to wealthy end-users and enterprise-scale services.
This is really great insight, and let me respond with what I know!
I think there are two fighting threads! One is “how can we make this so simple that everyone can use it with a single hardware key [that they must carry at all times and never lose and oh my god]” and “how can we provide a robust phishing-resistant authentication infrastructure that may require complex device management but not key management.” Like, I saw a lot of tech people saying, “A Yubico totally solves my mom/dad/relative’s login problems!” But then the response was always, “What happens when they lose the key or it’s damaged and can’t be used?”
A lot of people will be excluded at first, but fewer and fewer over time. The trick as I see it as follows:
In terms of back-end infrastructure, WebAuthn isn’t a huge bar, from what I can tell? Adam has checked it out for WordPress and doesn’t like the complexity of the current options. But there will be pressure for it, and I expect that ultimately it’ll be integrated into WP and other platforms as just another login option. WebAuthn doesn’t require patent payments or proprietary licensing, so that bar doesn’t exist, at least.
I think the question will be for sites that require or offer account logins, if they’re not engaged in banking, commerce, law, medicine, or government stuff, will they enable WebAuthn at all? Maybe, if users ask for it. But nobody has to invent the wheel or buy the wheel.
I imagine it really depends on interface presentation. If I’m offered in Android, Windows, or any Apple device the option to enroll in passkey account login and it’s presented in a way I understand, I might agree. 2FA enrollment is largely something you seek out or are chided to do; passkey upgrades might be suggested as a way to simplify and secure an account, thus offering honey instead of vinegar.
So what problem does a passkey solve? I know I went over this in the article, but it’s really solving 2FA’s complexity and management rather than necessarily replacing or improving on password-only logins. On the password-only side, a passkey has a number of security benefits users don’t necessary care about—they might, but is it a motivation? The simplicity coupled with promises of higher security and less risk might be the sales pitch.
Thanks for the detailed reply: I didn’t go into much depth because forums, tiny edit boxes, and rabbit holes are rarely great combinations, but I truly appreciate the time and depth of your response.
I absolutely agree that passkey has the potential to do an end-run around the complexity and requirements of 2FA systems, and improve on password-only logins. That’s a pretty low bar.
I would be curious what Apple’s numbers for 2FA enrollment are: they push it very hard on many platforms (and, since I personally can’t use it, and I’m keenly aware of each shove). The speculated 20–40% figure might be reasonable in North America. I imagine it varies elsewhere, but (as you note) unless Apple decides the figure is impressive enough to be a decent marketing point, we’ll never know. I am also curious how big a pain point 2FA is for Apple: for instance, I never saw techbros claiming Yubico solved their luddite relative’s problems with 2FA, but I did hear from several who managed to lock their luddite relatives out of their devices/services by foisting Yubico on them (because I had to undo it). In the same vein, I’ve seen firsthand many dozens of cases where people make new Apple IDs (giving up all their purchases, services, etc.) because they’ve been locked out of their AppleID and iCloud “recovery” is not always available/workable/etc. I don’t know if those experiences are representative of anything broader: we all see the world through different lenses, of course.
I also agree adoption is going to come down to not just availability on the device(s) consumers are using, but also to how easy it is to understand — and a lot of that will come down to interface. So far industry (and Apple’s) solutions to password management have been pretty poor. I hope passkey can raise the bar.
Thank you again!
It’s sort of impossible to know except that Apple requires it for new accounts. So if you think about the formula “people who turned it on intentionally,” “people who accepted Apple’s advice during setup or upgrade to turn it on,” “people who had 2SV forced to upgrade to 2FA,” and “people who have created new accounts in roughly the last 2+ years,” that has to add up to some fair number. Some features in iCloud can’t be enabled without 2FA, which likely drove adoption higher, too.
Not shocking. When people have told me over the last few years they were setting up family member Z with a Yubikey, my reaction was always: what do you do when they lose or break it, since you’re starting from a point that these folks are having trouble with basic password management and being susceptible to phishing!
Concur! I like the idea. Management among devices is really the key thing. I think Apple garnered a lot of insight in slowly expanding password management across platforms and into apps.
Sounds great. But when you do this, do you have any option or mechanism for pushing your credentials into these browsers so they don’t need to re-authenticate on subsequent sessions?
I know that sites can still push down authentication tokens to avoid repeated login requests, but when those tokens expire or are deleted, re-authentication will be necessary. And if the authentication mechanism is intended to be seamless and automatic, then I think we can expect sites to start using much shorter lifespans on these tokens.
If I need to be presenting my phone to scan QR codes every time I use a non-Apple browser (which is all the time for my desktop and laptop systems), it is not going to be a happy experience. Especially when the system becomes popular and web sites all over the place start switching over.
Anyway, since I’ve been talking about this rather extensively, let me share what I would like to see.
I’m a software developer and I’ve been using SSH for remote access for a very long time. This is both for my own computers and for various services provided by my employer and a few Internet services.
I generated by own personal key pair using the standard
ssh-keygenutility. I keep my private key to myself - copying it only to the computers in my home that I own and manage. I send the public key all over the place - to every site that can use it for authentication.
Usage is pretty much seamless. When I use SSH tools and software that has integrated SSH (like the git source code management system) to access a remote system, if that system has my public key, I immediately get access, without needing to do anything. If the site doesn’t have my public key, then it asks for a password.
I would like the FIDO/passkey system to behave similarly. Let me take my private key and manually install it on every computer/browser that I trust and then be able to forget about it.
I realize that Apple needs to put a very user-friendly interface over the mechanism, and they need to be alert for users who don’t understand the consequences of certain actions (e.g. giving the private key to an untrusted device), so they can’t leave it completely open the way SSH is, but I’m hoping Apple can find a way to meet these requirements without crippling the capabilities I make use of all the time in the SSH world.
Ah, not that I know of.
FWIW, there is an iCloud Passwords extension for Edge and Chrome on Windows, which allows you to use your iCloud Keychain passwords to log into sites (you must also install the iCloud desktop app, which Apple has published to the Microsoft Store). I’m sure support will be added for passkeys, if not in the fall, soon enough after this fall’s major software releases. I dunno if this solution would be “good enough” for everyone though.
But yeah, portability between all the platforms is hugely important, and I hope all of the folks partnering on this (Apple, Microsoft, Google, etc.) take that into account.
Besides liking the security aspects of this, since I am lazy I will probably adjust my browser habits. I hate writing passwords and even the use of 1Password is boring. If this only works well in Safari, I will login with Safari. I am really looking forward to getting started with this.
For anyone who’s concerned about passkeys, I think these are perhaps the most important details to keep in mind. No one is likely to be forced to change to passkeys for quite some time. Though you very well may want to for increased ease of use and security.
Great article @glennf thank you. Now I get it!
This is one of those ideas that at first blush seems like a great increase in security…but we’re going to lose a lot of convenience at least in the near and mid term because of a few issues. First off…websites need to be re-coded to use passkeys instead of userid/password combo…and this is going to take years at least…and some will have issues with version of Apache or whatever OS the host is running or similar software related reasons to not upgrade. Second…it needs to be cross platform…all of the major password managers are both cross platform and cross browser so unless the password managers get modified to store the passkeys instead of whatever regime Apple or Microsoft or whoever uses then from a usability standpoint this is a step backwards. For logins that actually matter…your bank, your utility company for payments, your financial guys and the like…the increase in security is probably worth the decrease in usability although if one uses a password manager that does the SSL verification so it’s not a fraudulent website spoof and you use good passwords then the security of logging in is still pretty good although the reduction in leaked password databases is a plus. However…for logging into tidbits or some non financial site…the loss of usability probably does not overcome the additional security.
Why is there any loss in usability? The upgrade process for sites is irrelevant to users, and while multi-ecosystem support will be useful, it’s not something most users need right away.
Passkeys aren’t going to happen overnight, but I don’t see any reason to be negative about it. Once there’s a decent plugin for WordPress, I certainly plan to support them for TidBITS logins to make things easier for those who can and want to use them.
I think it’s great to emphasize here that passkeys are, for the foreseeable future, a complementary login technology. Too much hype in headlines about passkeys has tried to shade that as “the death of passwords" or “password replacements.” For most sites, for most purposes, and for many years, it will be an enhanced method rather than the only method.
Fortunately, WebAuthn server modules and elements have been around for years now, they’re integrated into website hosting and account-management systems. For sites that want to add passkey login, they’ll do it as part of adding WebAuthn support, which allows FIDO2 hardware keys. Many larger sites already offer WebAuthn; I expect smaller ones, hosting companies, etc., will add it as customers demand. (It won’t be at an Apache level, but at a user-management system level: here’s a great explanation as to why.)
I’m not sure why this would be. If Amazon supports passkeys, for example, I would think that they would want to set a persistent cookie on the browser, just as they do today, to make it as easy as possible for people to continue shopping.
If Amazon logs me out for some reason now, I still need to log in to 1P on my computer (which doesn’t have Touch ID), then get/let it fill in the password, then I’m in. Basically logging in with passkey using my phone is going to be much the same (and, of course, if I am using a Mac on the same Apple ID as my phone and using Safari, I won’t even need to use my phone.)
Yeah…for almost everybody better security is the enemy of good enough security. It’s important to use complex passwords with all 4 of the basic password food groups of course…and it’s important not to reuse them across websites. However…since most of the password managers these days verify the SSL to make sure it’s not a fraudulent version of your bank’s website or whatever…then for most of us who aren’t specifically targeted good enough is really just that…good enough.
True…the extra benny of being protected against leaked password databases is a good thing…but given the inertia in getting most people to just not keep reusing the same password over and over…and given that it will be a long long time (if ever) before all websites shift over to passkey…and given the low target-ability of most people compared to somebody named Trump or Biden or Musk or whatever…anything that affects usability is going to be a downer. And unless I miss my guess…the not all websites will use it anytime soon combined with the apparent lack of cross browser, cross device, and cross platform compatibility along with sync to all of those different ecosystem devices is going to severely impact usability and hence adoption.
It Is a good idea technically but until it becomes simple, reliable, widely available and did I mention simple…most of the people that use passkey or FIDO or SQRL or whatever will be techbros or nerds…and not your grandmother.
The loss of usability is because it won’t be universal across websites…and at least to my minimal understanding to date passkey will be Apple ecosystem centric and stored in a different place than your regular passwords are (1PW or LastPass or whatever)…and grandma will have a hard time remembering where her login stuff is stored. Add in the cross platform and cross browser lack of compatibility and who knows what sync problems will happen…all of that makes it less usable to non technical users than whatever they’re using now I think.
As I said in other replies…this is good from a technical standpoint but from a user standpoint a lot of the time better is the enemy of good enough…and if better is more complicated/harder to remember/doesn’t autofill like your current password manager is no matter what browser or platform you’re using…then is better really better? Just like password complexity issues…a 30 character completely random password is technically superior to a 20 character 3 regular dictionary words separated by some symbol with first letters in upper case and a couple numbers on the end…but from a practical standpoint 3 trillion trillion centuries to crack provides almost zero security improvement over a billion centuries to crack.
Assuming the solution is cross browser, cross platform, cross OS, and sync works…and universal across the majority of websites…then usability is about the same. However…none of that appears to be the same in the cross/sync areas and universality will be a long time coming…and granny will likely be confused by the “is this a passkey site or a userid/password site” to know where to get her login info from, particularly if she uses Chrome or Firefox instead of Safari.
All of these issues may go away by the time this is implemented…but the time frame for that and the cross-everything-ness issue…not to mention the web upgrades…seems to be making this harder and less usable in the near and mid and even far mid term. After all…how long did it take websites to get rid of Flash even after Jobs simply refused to support it…a long time as I recall.
You’re right…big websites will probably convert pretty quickly but smaller ones will take a log longer…and the “what kind of site is this one” question will confuse a lot of non technical people. Heck…I haven’t even been able to convince my bride to shift away from Password Wallet despite its drawbacks (one man shop, no new features in at least 4 or 5 years, really bad autofill UI) to something more modern and fully featured…and she’s quite computer literate. Her excuse is that it works for her and no amount of cajoling by the guy that used to do computer security for a living has convinced her to switch even though I offered to do the conversion for her.
As I said…in the long term this is a good thing but we’re talking years to perhaps a decade before this is universal across sites, platforms, browsers, and operating systems and during that whole time things will be harder than they are now IMO. 1Password…despite my dislike and non interest in upgrading to v8…handles all of this transparently across platforms/browsers/OS/sync and just works. Until we see how it actually works in our to be released fall versions of our various Apple OS’s…it is really too soon to tell. Apple generally does a lot of things very well…but then they’ve had their fair share of failures as well…the whole CSAM rollout thing, the bloated mess that iTunes became, etc…but they claim everything they do is the best ever. That isn’t a fault and marketing will always say things like that…but it doesn’t necessarily make it true either. iCloud sync works pretty well now…but for a very long time it was much worse than DropBox was as another sample…despite them continually telling us it was fixed and the best thing since sliced bread.
My example of Apache capabilities would probably have been better stated as “web server” capabilities…I’m not a web server guru by any stretch of the imagination and was largely speaking to them as a system wide thing vice an Apache specific thing.
You’re right about the death of passwords headlines hype though…
Sure, it will be slightly different but since it walks the user through the login, it shouldn’t be problematic. Try the WebAuthn demo site on a device with Touch ID or Face ID.
I don’t really understand the various demo options, but when I register a random username, it prompts me to use Touch ID or Face ID to get credentials, and when I then try to log in, it uses the same authentication approach. Works like a charm.
So it’s hard to imagine someone having major trouble, assuming they’re savvy enough to understand logins to begin with. They type in their username, or their password manager fills it for them, and then they get a Touch ID or Face ID prompt, after which they’re in.
It’s already not universal across websites. The easiest allow me to access them immediately with login required once a month or so. Some allow auto-completion of my userID and password without me having to do anything but hit the Login button. A few force me to type my password, disallowing any pasting or auto-completion. Several require that I prove I’m human before the login button becomes active. A few require 2FA. And others somewhere in between. I seriously doubt that the passkey system will be vastly different than the variety of methods already in use today.
deep in the depths of memory, I recall a hardware device provided security code to login to PayPal, a rolling code if I recall.
Seemed so simple then in comparison to the absolute mess today.
So, “welcome” another layer to deter users.
That’s effectively what a FIDO key, but with no display!
nirvana would be a SSO Passkey that is Universal, cross every platform/system, not adding something new whilst everything else remains.
then life may be easier for Adam as it would enable seniors to self manage to a greater degree.
“ Helping Senior Citizens Reveals Past Apple Lapses and Recent Improvements “
How we’ve ‘ progressed ‘ since my first SE/30, where computing was slower, but productivity wasn’t hobbled.
Passkey won’t fix this, but I seriously considered divorcing from my iMac, MacPro, 3 iPads, until the MacStudio arrived.
Much of that due the inconsistencies in installing apps where there is massive divergence in enabling Security & Privacy permissions, screens pop and vanish. icons have to be dragged.
Got my first passkey today on iPhone. It was an login to a app I use at the local grocery store that prompted me if I would like to save a passkey.
Does anyone have thing to add to these concerns expressed by Jeff Johnson:
I respect Jeff and his work immensely. StopTheMadness absolutely and dramatically improved my web experience. He’s very much a Cory Doctorow for the Apple ecosystem: he speaks out early, loudly, and sometimes taking the extreme worst case—and, sadly, he’s often right to do so.
On passkeys, I think he’s expressing a lot of reasonable frustration for anyone who doesn’t want to slide into the warm embrace of iCloud and Apple’s default choices. It is an industry standard. The passkeys, by design, will be able to be managed and moved around in different ways. 1Password I hope will be one of the methods by which we can backup and sync apart from iCloud. Some of the passkey infrastructure is OS-embedded in order to provide the kinds of out-of-band security elements required, so some details remain to be sorted out for non-OS provided passkeys.
It’s definitely an issue now, though: there’s a short-term lock-in without details about how the long-term plan will emerge for portability and syncing. However, for most users, passkeys are a huge security improvement and, based on talking to 1,000s of Mac users over many years, most Mac users are all-in on the Apple ecosystem.
For sure, iCloud used to be very rough around the edges. I find it more reliable in the last couple years than ever before. I had a recurring iCloud Drive problem (saving a live file would often reload the last version of the file; couldn’t find anyone else with the problem; Ventura fixed it) that was my last rough edge.
I absolutely disagree with the intent of passkeys as Jeff is expressing them. It’s a significant security improvement over the current method. We’re in early days and that may deter some people from adopting them now until there’s better portability.
I also disagree with him about Yubikeys. It doesn’t fit his use case at all. These keys are intended to be with one at all times (like on a keychain) and designed to provide the requirement of physical proximity. The vast majority have no biometric component and that fits the design remit: they are meant when you know you can secure physical access and want it to be portable—works on any device and OS with supported websites or other components. The next level up is really using passkeys with biometrics: same technology, more secure interface that still requires an attacker to gain access to your hardware, and the biometrics add one additional level of protection.
I’d say Johnson is a member of a relatively small group of Apple users: people who are developers and people who are 70s-style computer hobbyists. Now that Apple has transformed its brand and most of its products into lifestyle and luxury statements–in Apple historical terms, Ive not Woz–passkeys will be a major benefit for both the vast majority of Apple’s customers and for all users of services that require logins. The faster we can all get away from passwords and SMS-based 2FA, the better.
Yes, yes, yes!
I’m still interested to learn how Apple is going to solve the Find My app issue if you’ve lost your phone and your phone is the only Apple ID device (or the only one with you.) For now, you can borrow an iPhone or iPad and log in to your Apple ID with a password in the Find My app, or in a web browser on a computer, without triggering the 2FA approval notification to a trusted device/trusted contact, so you can track your lost device. What happens when your Apple ID uses passkeys? Will you still be able to do this, and how?
Passkeys appear to be an improvement in the case of stolen/leaked/breach attacks that harvest a bunch of passwords in that they depend on public/private key pairs and if the bad guy steals your public key from google or wherever it doesn’t really let him log into your account because public is useless without the private one which only you have. However…if one has a good (i.e., long) password and the website has adequate security of their encrypted password database and there aren’t any previously unknown zero day flaws in their encryption algorithms then the long password pretty much protects you for a long time…hence unless you’re a specific high value target it’s not worth the computer time and expense to crack your password and the bad guys will just move on.
As Jeff says…they currently depend on iCloud which as we know is somewhat unreliable…and the number of websites that can use a passkey instead of a password is still pretty limited and will likely stay that way for years. I can see a day way in the future when most sites are using passkeys…and the various password managers (which are used by many of us to store a lot more than just passwords)…have all been updated to both adequately store, protect, and allow backup and restore on the user’s end of said passkeys…then they will be a good thing.
In the end though…for the vast majority of people who have sufficiently long passwords…it appears to me that the advantages of them over password are over emphasized by the people promoting them…
Yes…in a perfect world they’re better than passwords because of the enforced length and the you need the private key part…but it’s not a perfect world…and won’t be one for a long time. One of the things I learned way back in engineering school and that was relearned through 20 years in Uncle Sam’s Canoe Club driving submarines…and then again in my days as a budget guy and then an IT sysadmin…is that better is the enemy of good enough…and thus for many situations good enough is…well…good enough.
I hate to disagree…and I’m only partially anyway. Yes…in theory it is a significant improvement…but that’s much like looking t photos at 1:1 resolution in Lightroom and declaring one better than the other. The public/private key system makes it more secure…but the real question is whether that increase in security is meaningful. Assuming that the user is reasonably competent and has an adequately secure password…which in 2023 essentially only means long enough…and assuming that the website has decent security for its hashed password database, which most probably do as in 2023 few websites roll their own security…they use generally accepted and vetted libraries to do that because most web devs aren’t security experts…then at worst the website loses a copy of the encrypted database of hashed passwords. Given long passwords and not being a particularly attractive target like the President or AOC or whoever…the vast majority of users are of sufficiently low priority that the long password really provides good enough security since it isn’t worth the expense of trying to crack the password for the gain you will get out of it…in other words the vast, vast majority of users are low value targets. So…while technically you’re correct and it is better…in most cases this is an example of better is the enemy of good enough. So…for any reasonably technically competent user…switching to passkeys probably isn’t worth it until (a) the tech improves so they are easier to deal with and (b) they are mostly ubiquitous across the web…and that last element will require years at least. The passkey tech is simply too immature at this point to be worth the slight gain for a considerable effort IMO.
The qualms and questions about passkeys on this comment thread are illuminating. At best, the industry advocates have done a terrible job communicating when, why, and how to use passkeys. If TidBITS readers aren’t sure about passkeys, it’s not a promising sign for adoption of the technology. At worst, it may be a tech solution that has real benefits but never quite makes it beyond niche applications. (PGP-encrypted email, I’m looking at you!)
From a communications standpoint, if the general perception of passkeys becomes “It’s too complicated” in these early days, especially due to tech media hype, it may not matter if passkeys work well in the future. Once the original Newton became a punchline, it didn’t matter that the later eMate and the MessagePad 2100 were great devices.
Coincidentally, there was an interesting article today at Ars Technica about Google’s implementation of passkeys. I’m not sure that snarky headlines like “Google passkeys are a no-brainer. You’ve turned them on, right?” are helpful to the cause, especially for a 2,500 word article explaining the no-brainer.
(Sorry for deleting my previous comment. It was a little too clunky and really should have been a couple of comments.)
Especially when you’re a user who avoids all things google like the plague (Arc will NOT change the way I work on the web). I do like Ars in general, though.
I completely agree with Neil’s last two posts. I think there are a few key metrics: Is your bank or credit union using them? Is Amazon using them? Is Social Security using them? Is Medicare using them? Is the Department of Defense/VA using them?
For me, the answer to all those questions is currently no. And the only way I can get my wife to use good passwords is if I set them and “program” them into Safari so that she has to expend virtually zero effort to use them.
Well, she should be happy with passkeys then. That’s certainly where passkeys are better. They are always strong; they will be easy to use. Easier than user ID/password.
Those are two big assumptions for most people. Competence about passwords is generally not high.
One sure advantage of passkeys is that this is no longer a thing, nor is phishing for passwords. You can’t phish for a passkey.
FWIW, when it comes to iCloud Keychain, it has been absolutely reliable in my experience for quite a while.
I agree that Apple, Google, Microsoft, and the FIDO Alliance have done a very poor job of explaining passkeys and how they will work. I think they should have waited to publicize them until more of the details were worked out, particularly about how they’re going to work across platforms.
I wouldn’t read too much into the comments from the public though. It seems to me that many are knee-jerk reactions to rejecting anything that is new and different, and a lot of objections seem to be based on misunderstandings and misconceptions from people who haven’t taken the time to learn about passkeys. A lot of the blame, of course, lies with the poor communication by Apple, Google, and Microsoft, but individuals do bear some responsibility to not make claims based on ignorance.
I find your examples (other than Amazon) kind of amusing. In my experience, financial institutions and the government tend to be laggards when adopting modern security practices.
Actually…competence about passwords is pretty easy today…in reality the o ly thing that matters is length. Even standard dictionary words…inypterspersed with the first leyyer upper case, separated by & or $ or * and a digit or two on the end are just fine. Get the length to 20 or so and the only way it’s going to be broken is brute force…and for the vast majority of people it is simply not cost effective to try and crack it. As I said…most websites are no rolling their own security stuff…they’re using standard packages which for the most part are vetted…so at worst the encrypted password database gets leaked or stolen or whatever. That really doesn’t matter if your individual password is essentially unbreakable. We see ll these leaked password lists…but we’re they leaked in the clear or did they run Jon the Ripper or similar on it and break all the 8 character ones…that’s trivial but won’t crack any of the adequately long passwords.
As I said…from a purely technical standpoint passkeys are better…but as they exist today they re the enemy of good enough…to few sites, too many hurdles t9 backing them up and syncing them or moving them to another device, etc…eventually they will be ubiquitous and make sense but today they don’t for most people because of the growing pain issues. YMMV.
I know all this, but it remains that people in general do not practice this, do not even know this, still tend to use short, memorable passwords, reuse them across sites, etc. Recent article: Study reveals top 20 most used passwords; 83% can be cracked in a second - 9to5Mac
I would say most non-technical people I know still try to create their own passwords when confronted with a prompt, even on iPhone or iPad, when iCloud Keychain tries to recommend a good one.
When you need to manually enter a password – as for example when I’m logging into my Mac – anything more than about 10 characters gets to be a problem, especially if it’s randomized. It can take me several minutes to enter the roughly 20 characters of my WiFi password, because it’s on a paper master and I have no way to transfer a digital version to a new phone or device.
I now use suggested passwords much of the time, but I have found they may break when web addresses change, or when something else goes wrong.
Join the discussion in the TidBITS Discourse forum