Passkeys replacing the need for 2FA

TidBITS Talk
1

The faster we can escape from using passwords the better

The Fido Passkey solution is essentially a public / private key solution where a website / server will not hold your password but a public key instead. This means if the website / server is hacked your password cannot be stolen as there is no password. Only the public key which is worthless without the private key.

Your private keys reside on a security chip (Apple Secure Enclave inside the Apple Silicon SoC). You can write private keys to the Secure Enclave but not retrieve them. You can reset the Secure Enclave tossing all the private keys except the factory burned in private key. When you authenticate using a passkey, you receive the public key and it is sent to the Secure Enclave on your device. If it matches a private key within, then the chip answers YES if not NO. If YES, you are authenticated. Using a smartphone this can be done with a QR code embedded with the public key. If you are using a PC, smart TV for example. On the smartphone itself, the QR is not necessary it will just send the public key and iOS sends it to the Secure Enclave. Apple Silicon Macs as well.

The only problem with the Fido Passkey solution is the implementation of it on every website. I’ve run across several that were not as well put together as others. Sure it’s secure, but it’s maddeningly frustrating to use for most people. Others are smooth and simple. So it depends on the developers. In many cases it feels like an after-thought and zero time was spent on actual UX (User Experience) design. Someone on-high said, we need to add passkeys immediately. Dev’s just plug it into the system with little thought to the user experience.

Another option is a Yubikey USB-A / USB-C / NFC which is where you keep the private keys. This will work for any device that lacks a TPM / Secure Enclave chip. It’s more secure than TPM and on-par with the Secure Enclave. It’s recommended that you have multiple duplicate keys in the event you lose one or it’s stolen.

AppBITS: Proton Authenticator Takes on 2FA Apps
2

My understanding is that almost all websites that implement Passkeys also continue to maintain passwords as an alternative authentication method. As a result, Passkeys do not replace passwords, they simply augment passwords. And, passwords used prior to creating a Passkey is still active, meaning that the username/password credentials can still be used to access the account.

If these understandings are correct, then it seems to me that hackers who breach such a server are still able to access accounts that have a Passkey by decrypting the password file and using the username/password combination; they do not need access to any private keys to do so.

Passkey implementation is subject to usability issues, as you say. But poor implementation, continued support of previous credentials, may also result in backdoor access.

What am I misunderstanding about Passkey implementation on servers that also support traditional credentials?

3 Likes
3

You are absolutely correct. Besides the poor implementations, your point about the passwords still being kept is spot-on. You should have the option to remove the password if you have a passkey. You should not be required to set a password. Ideally you want to remove the password. But if you cannot, at least change the password to a very strong random password that would be unlikely to be cracked by brute force. But again, a poor implementation of security standards may result in the website being hacked and if they didn’t salt and encrypte the passwords properly. Game Over. The main reason to change over to passkeys. Apple, Google, Microsoft are all-in on Passkeys. They’ve all implemented the technology.

1 Like
4

I’d say even if passkeys are only a primary, not the only, login method on a site, there are still advantages. For example:

  • Protection against shoulder-surfing and keyloggers when the passkey method is used
  • Reduces incentives to use memorable and easy-to-guess passwords and user names
  • Existing user names and passwords can be made more complex, especially when they’re seldom used
  • Less use of SMS-text messages and voice calls for two-factor authentication
  • Less need to stay perpetually logged-in to websites and apps for convenience

In short, passkeys are something individuals can use to help reduce the security risks that arise in daily use of log-ins, e-commerce, and cloud activity. There isn’t much any of us can to do to defend against large scale breaches at companies and organizations, other than using the longest, most complex passwords possible in conjuction with 2FA. In any case, security these days requires a layered approach so I welcome passkeys as an additional tool for protecting myself from attackers.

5

Neither should be an issue with a passkey - especially if you are using biometrics to provide the passkey.

6

My health care system enabled passkeys, but requires two-factor authentication (SMS or email) even when using one.

1 Like
7

That’s unnecessary from a security standpoint (perhaps there is regulatory reason) but not harmful since an attacker can’t do anything with a 2FA code on its own.

—————
ETA:
Looks like PayPal, among other sites, is set up the same way (I haven’t fact checked any of these results).
https://www.perplexity.ai/search/what-are-some-websites-that-re-TTyuCuZmRwOEoiYBo0VDUw
—————and—————
This conversation was generated with Duck.ai (https://duck.ai) using OpenAI’s GPT-4o mini Model. AI chats may display inaccurate or offensive information (see Duck.ai Privacy Policy and Terms of Use for more info).

User prompt 1 of 1 - 8/11/2025, 2:27:12 PM:
What are some websites that require 2FA after logging with a passkey?

GPT-4o mini:

:globe_with_meridians: Websites Requiring 2FA After Logging in with a Passkey

Several websites and services have implemented passkey support, often requiring two-factor authentication (2FA) for enhanced security. Here are some notable examples:

Website Description 2FA Requirement
GitHub A platform for version control and collaboration. Requires 2FA if passkey is used for login.
Bitwarden A password manager that supports passkeys for easier access. 2FA is enforced when using passkeys.
Login.gov A U.S. government service for secure access to various government websites. Requires 2FA with multiple authentication methods.
Apple iCloud Cloud storage and services from Apple. 2FA is recommended when using passkeys.
WhatsApp Messaging service that supports passkeys for account security. 2FA is encouraged for added protection.
8

Ever since I started using 1Password (at least 15, probably approaching 20 years), I’ve been using a completely random unique password for each individual site. If any website is breached and the password is compromised, that password won’t be useful for any other site. I came to the realization a long time ago that websites were going to be breached, that threat actors would try using the username/password combination against other sites, and that the only reasonable defense would be unique passwords per site. Having them completely random minimizes the potential for hash table attacks - although I also use the maximum length that a site supports. I get frustrated at sites that only support short passwords (20, 12, even 8 characters).
I’ve upgraded to passkeys for all sites where it’s possible to do so, and I keep checking to see if it’s possible to remove the password altogether.

4 Likes
9

I wish that I could select a username as well as a password, but many sites want me to use my email address as my username.

3 Likes
10

Avoiding single dictionary words and common short phrases is important here. Completely random characters shouldn’t be necessary, and it does pretty much mandate the use of a password manager, because you will never be able to remember any such passwords.

FWIW, I usually take two or three words (that do not form a phrase, and are usually proper nouns from works of fiction), and apply creative misspellings to further discourage a dictionary attack, including whatever rules the site mandates, like special characters and numbers.

This has worked well for me and the results are easier to remember. I still use a password manager (the one built-in to Firefox), but primarily to guard against spoofed sites, since the browser won’t auto-fill anything into the wrong site.

Should I assume that you do all your browsing using one browser (Safari?)?

I like the concept of passkeys, but I use multiple browsers (Mostly Firefox, but also Safari, Edge and Chromium) on multiple computers running multiple operating systems (macOS, Windows, Linux, iOS and Android).

From what I’ve read so far, there is no mechanism that can synchronize passkeys across the entire pool of browsers that I use, and those that have tried have run into problems.

I know Firefox on macOS has a feature to synchronize passkeys from the system keychain, but I’m not sure if this will sync the rest of the way to Firefox installations on other computers and then into wherever Windows and Linux store secure credentials.

The way I see it, unless/until this synchronization can work reliably, I will not be able to remove password access, and if passwords aren’t removed, then it really doesn’t provide all that much protection over what I’m doing now.

1 Like
11

Supposedly it’s coming soon, as soon as the Apple 26 OSes for the Apple Passwords app. I believe it’s based a FIDO standard that others can/will adopt. Ars Technica recently had a story about this.

Which includes a link to the FIDO draft specification.

3 Likes
12

And FWIW…length is the only thing that really matters along with making sure you use upper and lower case long with numbers and special characters. Three or 4 words separated by some special and an uppercase in each then some numbers. As long as it is 20 or so characters long that’s plenty to o ensure that rainbow or dictionary attacks won’t work…and once you force a brute force attack long is your friend. And ypu can use actual dictionary words without the misspelling or character replacements…since the entire password must match the brute force guess.

2 Likes
13

Unfortunately as long as an email account is the user name, the length of password to the site may not matter quite so much - what may matter more is the strength of the password to your email account (as well as whether it has some sort of 2FA protection), as “I forgot my password” almost always lets you reset the account password from a link sent to your email account.

2 Likes
14

I am seeing more sites essentially using the “I forgot my password” method and just emailing a login link rather than asking for a password or passkey. Many retail sites that use Shopify are doing this.

Very annoying when one has created long, unique passwords along with 2FA (where possible) for each site.

2 Likes
15

True…which is why the email password should be set using the same criteria and 2FA if possible.

16

Yes. I’d just add another security measure to consider that can offset email link reset vulnerabilities is compartmentalization. For example, one can set up an email account solely dedicated to website registrations. Or keep the app that generates email account 2FA codes on a separate device from the device used to send and receive emails (a potential use for otherwise obsolete iPads, iPod Touches, and iPhones).

17

I use a number of browsers. Orion, Orion RC, Safari, Mobile Orion, Mobile Safari. Where the passkey is stored depends on the site and browser. Some of the passkeys get stored in the Apple keychain (I have 26 there at the moment, and they’re available from all of my Macs and iOS devices). Some of the passkeys are stored in 1Password (35 passkeys). A few are stored on my Yubikey (4), although it’s limited to 25 total passkeys.
The important thing to remember about a passkey is that it depends on a secure public key infrastructure - a device or a system that allows you to prove you are you. The website stores a public key, but the private key is stored in the device (for the purposes of the discussion, the Apple secure enclave, the 1Password system, the Yubikey device are all devices). The website encrypts a message with the stored public key, sends it to your device via the browser, and the device decrypts the message using the private key stored on the device, then sends a response back to the website. The private key never leaves your device, and is protected by either a biometric or password - you have to have posession of the device and the way to unlock (touch ID or face ID for the Apple secure enclave / iCloud keychain, PIN for the Yubikey, and the secret key and password - or touch ID/face ID after authenticating - for 1Password.

Six Colors have a fairly comprehensive (and recent) write-up:

18

I really dislike the “magic link” method, from a cybersecurity standpoint. It may be “easier”, but it can be easily compromised by anyone who has access to your email, including a man-in-the-middle attack. Perplexity AI is one site I’ve used that insists on using this method (you can’t choose an alternative method - they ONLY support the magic link by email method).

3 Likes
19

Ricky Mondello has written about why he sees a place for magic links. Personally, I hate them too.

20

There are certain use cases where they’re really bad, particularly with in-app browsers. For example, if you follow a paywalled publication on Facebook, and they only authenticate via “magic link”, then you have to authenticate every single time you click on one of their links in FB. Using the link from email will direct you to an authenticated session in Safari, and even though that will likely set a cookie that will leave you logged in for some time, that cookie will never be set in the in-app browser.

Dave

1 Like