Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over

Published on January 2, 2025.

Important Note: On this blog I speak only for myself as someone experienced in usable security and website authentication. I am not speaking for the company I work for. I encourage linking to and talking about this post, but if you can, please identify me without affiliation.[1]

Independent media venture 404 Media recently published a post titled, “We Don’t Want Your Password”. The piece is a cogent explanation of the problems with password-based accounts online followed by a defense of the website’s login strategy, magic links, in the face of feedback about them being inconvenient and difficult to use.

I applaud 404 Media for having the courage to do what they feel is best for them and their customers, even if their customers may not expect it, and I give them a standing ovation for remaining resolute, but thoughtful, in the face of complaints. Passwords are deeply entrenched, and straying from the expected or default path for any kind of service, much less a media venture, is taking a risk. I’ve been meaning to write about my frustrations with and appreciation for magic links for some time now, and the steadfastness and clarity of this post pushed me over the edge to do it.

Obviously, authenticating to websites isn’t an either-or binary between passwords and magic links. Passkeys — the next-generation authentication standard defined by the FIDO Alliance and W3C, with backing from all of the major platforms, browsers, and credential managers — can be layered nicely into a magic link-based system to give users a secure and fast sign-in experience without the frustrations that come with switching apps to refresh one’s email. They’re complementary technologies, because passkeys can do this in a way that seamlessly coexists with, and is in fact supported by, email magic links for people who don’t yet have a passkey, don’t want a passkey, don’t have the device stability to use passkeys, or would prefer to sign in with a magic link this one time.

You’ve almost certainly encountered magic links in your time online. A “magic link” is just the special, one-time link you get emailed to you that will sign you into a website after giving it your email address. And if you’re reading this post, there’s a good chance that you use a password manager and that you find magic links to be far slower than using your password manager to sign into a website.


They frustrate me, too. My local grocery store, one of the many Albertsons companies, has taken to preferring an email magic link over my easily-AutoFilled password, and it frustrates me every single time I try to sign in. Once you’ve experienced a world where signing in to websites and apps is so seamless it requires next to no thought, while still being secure, you never want to go back.

But I also kind of love magic links, because they acknowledge — no, radically accept — some fundamental truths. Namely, that…

  1. almost all online accounts can eventually be signed into by proving possession of an email address; this is usually phrased as “forgot password?”
  2. many of the people who don’t use password managers use that “forgot password?” flow every time they sign in because people cannot use passwords effectively; why shouldn’t they just make that the user experience for everyone, or at least, the default flow?
  3. merely having a password for a service opens a user to attacks like credential stuffing, which is when stolen account credentials are used to gain access to accounts on other systems; credential stuffing is particularly effective because people reuse passwords

The title of 404 Media’s piece very powerfully acknowledges point 3 by saying, “We Don’t Want Your Password”, singular, acknowledging that most people have on average approximately 0.8 correct passwords in their memory at a time. And they’re willing to cop to the negative feedback they’ve gotten, writing:

Probably the most common problem people run into with magic links is they think they have logged into the site on their normal browser, but they’re actually logged in through an in-app browser. For example, someone might receive the login link to their email. They open up the Gmail app, click the “Sign in to 404 Media” button, and their phone loads the webpage. But this is loading the website in Gmail’s web browser, not your native Safari one.

In-app web browsers are unlikely to go anywhere any time soon[2], so the post describes how to work around the problem:

A solution on iPhone is when receiving the login link, click and hold the “Sign in to 404 Media” button to bring up the contextual venue, and hit “Open Link.” This will open the link, and sign you in, on your native browser. Or, copy and paste the sign in link which is also in the email.

Them calling this out is a tell; we can infer that these complaints are a real problem for 404 Media because they saw value in addressing a very specific user experience complaint. The way that their business works is that people directly pay to read their journalism; anything that stands in the way of people getting their money’s worth can impact their bottom line. I can’t say that my local grocery store’s strong preference for magic links has stopped me from being a customer, but that’s likely because I live in an area where they have an effective monopoly.

Something that I’ve learned by working on the user experience around website and app authentication is that, if you need to educate a person to go against what the inline flow naturally leads them to do, that cognitive friction will frustrate or stymie a significant number of people.[3]

Despite these drawbacks, I think that proving possession of an email address as a mechanism for signing into an online account is valuable and has its place for many, but not all, websites and apps, because email is decentralized and universal, email account providers are very highly incentivized entities to protect user accounts (e.g. Apple, Google, or Microsoft aggressively drive email account security forward), and ultimately, most people can follow instructions to check their email. This is of a kind with my belief that although it is far from ideal, SMS 2FA has its place, because authentication technology is all about threat modeling and what actually works in practice.

Passkeys

I’m going to assume that you know what passkeys are and that you’ve used them with your Google, PayPal, or TikTok account, or some other online account. If you need a refresher, I’ll plug my four minute video explanation of passkeys from a few years back that holds up pretty well today.

For the purpose of improving a passwordless authentication strategy using magic links, what’s important to remember is that passkeys suffer from none of the security problems that passwords have, and that signing in with passkeys is super fast, keeps users in their context, and never requires switching over to another app.

When it comes to speed and ease of use, in an April 2024 update on their passkey rollout, Google claimed that passkeys are 50% faster than passwords. And in my personal experience, signing in with passkey can sometimes be an order of magnitude faster than signing in with a magic link.

On iOS and Android, in notable contrast to magic links, passkeys are directly usable across web browser apps and system web view experiences. (Really. Any passkey saved and usable in Safari, whether in Apple Passwords or an app like 1Password, is usable in Chrome for iOS, Firefox for iOS, Gmail for iOS, and more.) So if a user follows a link to 404 Media in any web browser or in any email or social media app that makes use of the system web view, they can use their passkey to sign in within seconds. This is even true in web browsers like Chrome and Firefox on macOS!

For a user to sign in with a magic link, they first need to type or AutoFill their email address into a text field on a website.

Here’s the magic: Passkeys can seamlessly integrate into AutoFill.[4] Instead of filling the literal email address, AutoFill can sign the user in with one tap and a Face ID, while behind the scenes performing the strong authentication that powers passkeys. Here’s a six-second video showing me using AutoFill and a passkey to sign into my Google account in Safari on my iPhone:

Video showing opening the Google sign-in page loading in Safari. The page has a single “Email or phone” field. Near-instantly after the page loads, an AutoFill affordance appears, saying, “Sign in to google.com with your passkey for “email@example.com”?”. It features a big blue button that reads, “Use Passkey”, and tapping it performs a Face ID that signs me in.

The most important part of this experience is that it causes zero disruptions for people who don’t already have a passkey. Here’s what’s visible in Safari on my iPhone when I don’t have a saved passkey:

Screenshot of the Google sign-in page in Safari. The page has a single “Email or phone” field. The standard text insertion keyboard is present.

You’ll notice that this looks like a totally pedestrian web form asking the user to enter their email address. The Google website has still asked the browser to help it sign in using a passkey, but since I don’t have one, I’m left to type my email address.

The website of my grocery store, as well as 404 Media’s website, could work exactly the same way, with a field for the user’s email address that is progressively enhanced to have passkey sign-in when it’s available. And all of this works without a password. (For a resource on how to implement something like this, see the footnote attached to this sentence.[5])

To start, websites using magic links can make passkeys an optional, opt-in feature for the customers who have complained about how their magic links work today. To ensure it doesn’t cause any problems, as a sort of soft launch, they could make the feature 100% opt-in.

Slightly later on, once the people running the website are convinced that passkeys really help with the user experience issues around magic links, they can prompt users to add passkeys after signing in, once every 90 days or so, or whenever they sign-in using the cross-device sign-in feature of passkeys[6]. The framing of such a prompt can be something like this for users on Apple devices: Want to avoid having to check your email next time? Set up a passkey to use Face ID or Touch ID to sign in quickly and securely.

The Role of Software Platforms

The user experience and security of what I’ve demonstrated are a clear improvement over either password-based sign-in or a magic links-only experience, but in the world of running a business, nothing is free. In fact, doing literally anything at any kind of scale takes a lot more work than any of us like to think, especially for folks who have gone independent. A corporation like Albertsons may be able to afford to build and deploy passkey support, but developing and deploying a one-off feature like passkey support in 404 Media’s content management system almost certainly will not be worth the cost to them as a small business in the struggling field of online journalism.

And yet, I still wrote this post! Why is that? :)

Like a large portion of the web, 404 Media is using an open software platform (in this case, Ghost) to power their venture. If the world can convince Ghost and other platforms like WordPress and Mastodon to support passkeys, and maybe even contribute time, money, or expertise to make it happen, a huge number of people stand to benefit.

Resources

If you’re in a position to implement passkeys or influence an organization to implement them, I think it’s time to evaluate, engage with, and implement passkeys. Here are some resources I recommend you check out:

I’m also personally happy to answer questions and talk with folks considering adopting passkeys. I’m serious — hit me up.

Takeaways

I want to see my friends, family, and people who I will never meet no longer harmed by passwords, and I have dedicated the last five years of my career to dethroning them as the default credential for websites and apps. Passkeys aren’t perfect, because nothing is, but myself and other members of the FIDO Alliance are always listening to feedback and working to improve them. And as they exist today, they can clearly make the experience of signing into websites faster and easier than before.

Again, if you have questions about passkeys or authentication technologies in general, feel free to hit me up on Mastodon or Bluesky. I hope you learned something, and thanks for reading!

  1. As you can tell, I am taking great pains to not have my blog meaningfully affiliated with my employer. I am doing this to respect my employer’s desire to not have employees interpreted as speaking for the company when they are speaking only for themselves. As a proud member of technology standards organizations with noble goals, and as an independent person, I hope I can help the industry by contributing my perspective from time to time. If being pressured to not emphasize my employer in a link post dissuades you from linking to it, then I didn’t deserve your link in the first place. :)  ↩

  2. The incentives, economics, and privacy considerations around in-app web browsers is a fascinating and important story, but one I am not able to tell.  ↩

  3. If you’ll give me some leeway, I think it’s analogous to password management software in that password management software has a ceiling to the number of people it can help, because fundamentally, it is laying instructions and a process on top of websites and apps that expect people to create and type passwords by hand. The dissonance that I’m describing here is similar to the difficult to remember to do advice to copy and paste a sign-in link that is screaming to be tapped. This advice is almost begging you to inhabit the mental model of how browser cookies work, which is something that normal people shouldn’t have to do.

    This ceiling for the number of people password management software can help is part of why I believe so strongly in passkeys. A single, attractive affordance for signing in can confuse fewer people than whatever a password manager lays on top of a web page.  ↩

  4. In WebAuthn parlance, the use of passkeys with the AutoFill user experience is called “conditional mediation”. It’s not just a powerful tool for integrating with magic links, but also with existing password-based sign-in experiences.  ↩

  5. WebAuthn Conditional UI (Passkeys Autofill) Technical Explanation, a post from the Cordabo blog, goes into detail on how to implement conditional mediation for passkeys.  ↩

  6. As demonstrated in the four minute video I linked to, passkeys can be used to sign in across devices. So I can use a passkey on my iPhone to sign into a website on a Windows PC. Websites can detect when this happens, and should turn around and ask the user to register another passkey on the “new” device.  ↩

Apple Passwords’ Generated Strong Password Format

Published on October 7, 2024.

This post briefly summarizes part of a talk I gave in 2018. All information in this post has been accessible on YouTube since then. There is no new information or news in this post.

On Mastodon recently, jsveningsson@mastodon.social asked me:

Having an annoying argument on Threads about Apple generated passwords. Every iOS Password (like hupvEw-fodne1-qabjyg) seems to be constructed from gibberish two-syllable “words”. Hup-vew, fod-ne and qab-jyg above. Is this all in my head? Am I going crazy? Is the two-syllable thing by design or random?

This is not in their head, they are not “going crazy”, and the two-syllable thing is by design. Let me explain!

I gave a talk in 2018 called, “How iOS Encourages Healthy Password Practices”, that told the story of this generated password format. Although the talk is a bit dated now, it also covers other topics related to password management that, given that you’re reading this post, you might be interested in.

I explain the thinking behind the generated strong password format at 18 minutes and 30 seconds into the video:

To make these passwords easier to type on suboptimal keyboard layouts like my colleague’s game controller, where the mode switching might be difficult, these new passwords are actually dominated by lowercase characters. And to make it easier to short-term have in your head little chunks of it to bring over to the other device, the passwords are based on syllables. That’s consonant, vowel, consonant patterns. With these considerations put together, in our experience, these passwords are actually a lot easier to type on a foreign, weird keyboard, in the rare instances where that might be needed for some of our users.

And we weren’t going to make any changes to our password format unless we can guarantee that it was as strong or stronger than our old format. So if you want to talk in terms of Shannon entropy once again, these new passwords have 71 bits of entropy, up from the 69 from the previous format. And a little tidbit for folks who are trying to match our math — [note that] we actually have a dictionary of offensive terms on device that we filter these generated passwords against and we’ll skip over passwords that we generate that contain those offensive substrings.

…

So these new passwords are 20 characters long. They contain the standard stuff, an uppercase character. They’re dominated by lowercase. We chose a symbol to use, which is hyphen. We put two of them in there, and a single [digit]. We picked this length and the mix of characters to be compatible with a good mix of existing websites.

And a few more details: These aren’t real syllables as defined by any language. We have a certain number of characters we consider to be consonants, which is 19. Another set we consider to be vowels, which is six. And we pick them at random. There are five positions for where the digit can go, which is on either side of the hyphen or at the end of the password.

So yes, the passwords that Apple Passwords generates do contain gibberish two-syllable “words”. The syllables help them to be memorable briefly, but still not memorizable. I hope this helps!

New Quirks in the Password Manager Resources open source project

Published on September 29, 2024.

Note: This post is intended for people interested in using and contributing to the Password Manager Resources open source project. I am writing it in a personal capacity, as a maintainer and contributor to an open source project that I am passionate about.

I recently contributed two new quirks to the Password Manager Resources open source project that I want folks to know about.

(Quirks? Open source project? This open source project is, “a place for creators and users of password managers to collaborate on resources to make password management better”. The project contains “quirks” — data that pertains to specific websites, that can make the experience of using a password manager on those websites better.)

The first quirk expresses relationships between apps and websites. From the project README:

The file apple-appIDs-to-domains-shared-credentials.json expresses relationships between apps running on macOS, iOS, and iPadOS, and domains that use the same credentials. Information in this file is used by iOS and iPadOS (since version 17.4) and macOS (since version 14.4) for suggesting credentials in apps that do not have an association with domains. The system AutoFill capability makes use of this information to improve the user experience of signing into these apps by giving users inline suggestions of the appropriate credentials when signing in. This works for all password managers that make use of the Credential Provider Extension mechanism.

The JSON file is a map from App Identifier to an array of domains. Domains should be ordered by prominence from most prominent to least. The apps do not need to be distributed on Apple’s App Store.

That is, if you know of an app that doesn’t get specific passwords suggested on the QuickType bar, and instead has a generic “Passwords…” button, you can file an issue about it or contribute a fix.

The second quirk is a bit more esoteric. From the project README:

The file quirks/websites-that-ask-for-credentials-for-other-services-when-embedded-as-third-party.json contains a JSON array of domains that, when embedded as a third party, are known to ask for credentials for other services. For example, some payment processors conduct transactions by being embedded in an <iframe> on a website. These payment processors may ask for banking credentials directly, without using OAuth.

A password manager may wish to not offer to save a new password submitted in such an <iframe>, because the credentials are likely to not be for the service itself.

I love this project. It’s been a delight to work with folks at 1Password, Dashlane, and the enthusiastic users of password managers to make password management better for everyone. If you’re interested in contributing to the project, it’s pretty easy, and you’ll be joining the over 200 people who already have made contributions!

Thanks for dropping by to learn about these two new quirks. :)