Archives for March 2026

Last week’s article about passkeys generated a ton of questions, about how they work behind the scenes, how to use them, why they’re generally safer than passwords, and more.

As far as how they work behind the scenes (the public key/private key topic), that’s not something that you need to understand deeply (or at all, really) in order to use them and in order for them to improve your security. I simply included it because I know that many of the people who read this blog are the type who do want to understand the mechanics of how things work.

As far as what it’s like (from a user interface perspective) to actually use passkeys, it’s hard to explain universally what the process looks like, because it varies somewhat by website. (For example, when signing into Amazon with a passkey, they still send a 6-digit code by text, whereas most websites will not do so.) And it varies significantly based on what devices/browsers you’re using, as well as based on whether you’re using a separate password manager. For example:

• If you’re an Apple-only household, you browse only with Safari, and you use Apple Passwords to store your passwords, the whole thing will feel pretty seamless, with Apple Passwords storing your passkeys as well.
• If you’re on macOS, browsing with Chrome, and you use Bitwarden password manager, then Apple Passwords, Google Password Manager, and Bitwarden will each want to be the thing that stores your passkeys.

I would encourage you, next time you encounter a website that a) offers the option to use a passkey and b) is a low-stakes website for you so that it does not feel scary, create a passkey and then use that passkey to sign in going forward. Get used to using a passkey on one single website before trying to implement them more broadly.

For me personally, that would be something like target.com or walmart.com. Both of those websites have my name, email, shipping address, and my (not very lengthy nor particularly privacy-sensitive) order history. But neither has stored payment information, neither has my SSN, neither is linked to any financial accounts, etc.

Other Recommended Reading

• The Fallacy of Investing Based on Forecasts from Allan Roth
• An Asset-Liability Mismatch from Ben Carlson
• Dimensional Grafts Vanguard’s Tax-Busting Model Onto Mutual Fund from Katie Greifeld
• What’s Middle Class in NYC? from Ben Carlson
• Private Credit’s Angry Investors Are Showing Its Limits from Paul Davies
• The Best Strategies for Consistent Retirement Spending from Amy Arnott
• How do frontier AI agents perform in multi-step cyber-attack scenarios?
• Banks Are (Trying to Become) Bulwarks for Vulnerable Seniors from Paula Span (NYT)
• The Biggest Benefits Come from Consistency, Not Complicated Programs from the American College of Sports Medicine’s Updated Guidelines for Resistance Training

Thanks for reading!

Passkeys are a brilliant idea — a rare win, in that they are more secure than signing in with a password and (generally) easier to use as well.

A very short summary is that when signing in with a passkey, the authentication happens on your own device. So if I’m signing in via passkey, my device essentially asks, “hey user, prove to me that you’re the person who is allowed to unlock this device.” Once I do that (e.g., by PIN or fingerprint), the message the device sends to the other institution is basically, “this device has verified the user, and they have access to the passkey for this account.” So it has benefits such as:

• No reusable secret information is being transmitted.
• The institution doesn’t have to store any secret information (i.e., password).
• It has the potential to eliminate the risk of somebody guessing/stealing your password, because somebody would have to be in possession of your device and be able to convince the device that they’re you.
• It’s resistant to MFA-code phishing (such as in the John/Rachel example), because there’s no code to share in the first place.
• It’s also resistant to fake-website phishing attempts (e.g., somebody buying Vamguard.com and putting a site up that looks exactly like Vanguard, with a login page to collect login credentials), because passkeys are tied to a specific domain, so they won’t work on look-alike sites like Vamguard.com.
• It’s (usually) easier to sign in with a passkey than with a password, and passkeys eliminate the hassle of resetting passwords due to forgetting.

How Do Passkeys Work?

When trying to understand how passkeys work, it’s helpful to keep in mind the goal. The goal is to have a system in which a user can sign into a website or app without having to transmit any secret information. All of the secret stuff lives on the user’s own device. And everything that gets transmitted, and any login-related info that’s stored on the website’s server is safe if anybody else sees it.

But how can you log into a website without sending them your password or some other secret information? That is, if you don’t have to transmit any secret information to the website (i.e., if only “public” information is necessary), how can the website make sure that nobody else can sign into your account? To create a system that works in such a way requires fundamentally rethinking the entire process.

And that’s what passkeys do. They solve those problems.

And broadly, the idea is that the “proving you’re who you say you are” process happens locally, on your own device.

We’ll go through it step-by-step (i.e., what happens when you create a passkey, and then what happens when you use that passkey to log in).

But first we have to start with one piece of jargon.

What is a “Challenge?”

In order to understand passkeys, you have to understand what a “challenge” is.

You can think of a challenge as a formalized “who are you, and please prove it” request.

An “unsigned challenge” is what the server sends to you. For example, if you’re on your bank’s website and you click “log in with a passkey” or if you’re already signed in and you click a link to create a new passkey, your bank will send an unsigned challenge to your browser.

And what your device will eventually send back to the server is a “signed challenge” (along with some other information). We’ll get to how a challenge is satisfied (“signed”) in a moment.

For now, one thing to know about a challenge is that each one has a unique identifier (e.g., challenge #203SNA30DNDQ), and each challenge is one-time-use-only. This is a critical security feature. It means that if somebody managed to spy on your transmission (and were thus able to view the signed challenge that you send to the server in order to log in), they would not be able to simply copy that signed challenge and send it to the server themselves in order to log into your account. The server would say, “sorry, this challenge has already been used,” and the fraudulent login attempt would be rejected.

Magic Pen and Magic Magnifying Glass

With “challenge” defined, let’s take a brief detour for an analogy, to explain the other major parts of the passkey ecosystem.

Imagine you have a magic pen. It writes in normal-looking ink. But you also have a magic magnifying glass. When this magic magnifying glass is used to examine something that was written with your magic pen, the ink glows sparkly purple. When it looks at anything written with any other ink (i.e., not written by your magic pen) the ink just looks normal.

There’s no way to “reverse engineer” the magic pen from the magic magnifying glass. In other words, if somebody were to have the magnifying glass, there’s no risk that they could create a copy of your magic pen.

So you give magic magnifying glasses to all of your friends. That way, any of them can see whether a message was really written by you, with your magic pen. Fun! And you can give out as many of these magnifying glasses as you want, because again, nobody can recreate your magic pen just by having one of these magnifying glasses.

What Happens When You Create a Passkey

When you’re signed into a website or app, and you choose to create a new passkey, the server will send your device a new unsigned challenge.

Your device takes that unsigned challenge and creates three new things:

1. A private key.
2. A corresponding public key.
3. A credential ID. This is just a public identifier for the passkey (e.g., your new passkey is passkey #22093948310930).

The private key is the secret thing. The private key lives on your device (or is synced securely across your devices via your Apple/Google/Microsoft account) and is never sent to the server. The private key is your magic pen, and it can be used to sign a challenge.

The public key is unique and linked to the private key. The public key is the magic magnifying glass. It’s essentially a testing tool. When somebody has the public key, they can use it to test the signed challenge to see if it was signed with the private key (magic pen) that corresponds to that public key (magic magnifying glass).

An important point here is that there is no way for somebody to look at a given public key and determine the corresponding private key. So it’s absolutely no problem if somebody were to intercept your public key. Just like with the magnifying glass, you could give out your public key to as many parties as you want, with no security risk.

After your device creates these three things (private key, public key, credential ID), it uses the newly-formed private key (magic pen) to sign the challenge. And it sends the public key, the credential ID, and the signed challenge back to the server. It does not send the private key to the server.

The server then stores the public key and credential ID and associates them with your specific user. (Remember, you’re already logged in before beginning the process of creating a passkey, so it already knows who you are.)

So at this point:

• You have a private key (magic pen) stored on your device.
• And the server has a public key (magic magnifying glass) and a credential ID, both of which are now associated with your user.

What Happens When You Log in with a Passkey

When you initiate the process to log in with a passkey, your device first checks: “Do I have a passkey saved for this app/website?”

This step is itself a valuable security measure. It means that if you ever accidentally visit a fake website (e.g., you fell for the first part of a phishing attempt, clicked the link in the email, and are now on usbamk.com rather than usbank.com), your device will immediately stop the process. It doesn’t have a passkey associated with this domain. Disaster averted. (Though seriously, please don’t click that link in the first place.)

If your device sees that it does have a passkey for the website/app in question, the website/app sends an unsigned challenge to your device.

Your device then goes through some process to satisfy itself that you are you. This might be entering your device PIN or providing some biometric identifier (e.g., fingerprint).

Once your device is satisfied that you are you, it uses the stored private key to sign the challenge.

And your device then sends the signed challenge, the credential ID, and your username to the server. Again, it does not send the private key. (Also note: your PIN/fingerprint is never transmitted to the server either.)

The server then:

1. Checks that the username provided exists in the system,
2. Checks that the credential ID a) exists in the system and b) is linked to the username in question, and
3. Uses the stored public key (magnifying glass) that’s associated with the credential ID in question to test the signed challenge, to make sure that it was signed by the appropriate private key (magic pen).

If all three of those things proceed happily, you’re signed in.

Passkey Limitations

An important issue to be aware of is that, at least as of right now, when websites let you use passkeys, they usually let you sign in using the passkey or a password. So the weak password/stolen password path of attack still works. Ideally we’d see websites that let you implement passkeys and then make it impossible to sign in with a traditional password. But so far, that sounds scary to many users because passkeys are unfamiliar. Hopefully that changes over the coming years as more and more people use them.

In addition, there’s messiness where everybody wants you to use their passkey ecosystem. So if you’re browsing on Chrome on an iPhone, and you visit a website for which you already have a passkey set up (via Apple), Chrome might prompt you to create a new one — which can feel very confusing. Fortunately, you can usually create a bunch of passkeys for the same website, so you can have one for each device/browser combination, for each website.

When a website requires somebody to set up multi-factor authentication (MFA), it often provides multiple options such as:

• Email
• SMS (text)
• Authenticator app

Of the three, using an authenticator app is definitely the most secure approach. (Hardware authenticators such as a Yubikey will be a topic for another day.)

The Problem with Email as MFA

Email as the multi-factor authentication method is pretty bad. Just think of how many websites you visit where:

1. Your username is your email address, and
2. When you click the “forgot password” link, they just send an email with a reset password link.

If #1 and #2 are true and you use your email as the multi-factor method, if a thief gets into your email account, they can now access any of those other accounts as well.

Granted, a thief getting access to your email account is extremely bad news as it is. We want to take serious precautions to avoid that scenario. But there’s no reason to make that scenario any more disastrous than it needs to be.

SMS (Text) Isn’t Secure

Using SMS (text) as the multi-factor method is not ideal either.

CISA (the Cybersecurity and Infrastructure Security Agency, which is a component of the United States Department of Homeland Security) put out a document in December 2024 that encouraged people to “migrate away from SMS-based MFA.” They note that “SMS messages are not encrypted — a threat actor with access to a telecommunication provider’s network who intercepts these messages can read them.” They also note that SMS is not phishing-resistant (see the John/Rachel example).

SIM-Swap Fraud

Another problem with SMS at the multi-factor authentication method: SIM-swap fraud.

Mobile providers can easily “port” a phone number from one device to another. This is commonly done when a customer switches to a new phone (e.g., to upgrade or because the previous device was lost).

In a SIM-swap fraud:

• The thief gathers personal information about the target. As we’ve discussed, a lot of information is simply purchasable. Other assorted information can often be gathered via social media or online searches (e.g., mother’s maiden name may be findable via an obituary posting).
• The thief then contacts the target’s mobile provider and, with clever conversational skills and a bunch of personal (ostensibly private) information, convinces the company to transfer the target’s phone number to the thief’s device.

And now the thief has access to any MFA codes that come in via text. And again, as discussed recently, in many cases that code is all they need, in order to access various critical accounts.

Your mobile provider probably offers a SIM-swap protection feature. Verizon, T-Mobile, and AT&T all provide it free of charge, but it isn’t activated by default. I would definitely encourage you to turn it on.

Even with SIM-swap protection activated via your mobile provider though, SMS is still not the ideal method for multi-factor authentication, because SMS is not encrypted.

Authenticator Apps

Authenticator apps are more secure than SMS or email as the multi-factor method. The authenticator app is installed on your phone and cannot be accessed remotely (short of your phone itself being infected with malware). To get an MFA code from an authenticator app on your phone, the thief would have to:

• Be in physical possession of your unlocked phone, or
• Convince you to give them the code (which is also a potential failure point of email or text-based MFA). And again this is why we have to be super careful with these codes.

Authenticator apps take a bit of time to get used to, but once you’re used to using one, it’s quite easy. I have found Google Authenticator to be easy to use, but there are many other options as well (e.g., Microsoft Authenticator or Authy).

If you’re new to it, do not worry, regardless of which authenticator app you pick, there will be a ton of intro/walk-through videos on YouTube.

When setting up app-based multi-factor authentication, the website may give you the option to store some backup codes. These codes are to be used in case you lose your phone, so do store them somewhere. But of course make sure it’s somewhere safe (e.g., printing them out and storing in a safe or secure filing cabinet).

Removing Less-Secure MFA Methods

After activating multi-factor authentication by app, you may have to manually turn off multi-factor authentication via SMS/email. For many websites, the default behavior is that, if you already had some other method of MFA set up, after setting up MFA via authenticator app, that previous method will still remain as an option. And we usually don’t want that, because it leaves you vulnerable to exactly the types of attacks discussed above.

Continuing with our theme of cybersecurity, I read an article this week about a new software product for fraudsters:

• Phishing Software as a Service (Complete with Customer Support) from Callie Baron and Piotr Wojtyla

With this software, the user (a would-be thief) types in a URL of a genuine website, and when a target visits a selected scam URL, the software loads up an invisible browser window to collect, in real-time, all of the genuine website’s information, which it then passes through to the victim’s browser window. In other words, from the victim’s perspective, everything looks exactly right, because it is literally the same thing showing in your browser.

But it gets crazier from there. Much crazier. The software also passes every keystroke and action from the victim back to the original website — including the MFA code. So from the victim’s perspective, everything is operating as normal, including all of the functionality after logging in, so as not to set off any mental alarms. But the software is collecting all of that information for the thief. And the thief is now logged in as well.

The software also has a full collection of other features, such as URL masking (i.e., making a fake link look genuine).

And it comes with customer support, regular software updates, and a community forum for users.

The takeaway, again: unless you yourself directly typed the appropriate URL into your browser (e.g., vanguard.com, schwab.com, chase.com, etc.), you might not be on the genuine website.