Passkeys for WordPress: Everything You Need to Know with Tim Nash

Robert Abela: Thank you, everyone, for joining us today. Before we jump into today’s interesting discussion about passkeys, some news from our end. We have just published our 2025 year review on the website. So if you want to learn more about what we’re doing at Melapress, head to melapress.com, and on our blog, you can see our 2025 review. Also, next week we have two updates coming up: we’ll be releasing an update of the Melapress Login Security plugin and also an update of the WP Activity Log plugin.

Today’s guest is the first official repeat guest. I’m sure many of you know him, or you’ve seen some of his presentations – Tim Nash. How are you, Tim?

Tim Nash: Hello! I’m doing well. How are you?

Robert Abela: I’m good, thanks. Thanks for joining me. Just in case, for those who don’t know you, do you want to tell us a bit about what you do?

Tim Nash: My name is Tim Nash. I’m a WordPress security consultant based in the UK. I help small, medium, large, and giant organisations stay secure and keep their WordPress websites secure. I’m also the founder and principal teacher at WP Security 101, which is a WordPress security course.

Robert Abela: Nice. Thanks for joining us, Tim. Today, we’d like to talk about passkeys. I’m sure some people have heard about it; some probably didn’t. Those who heard about it may not be familiar. So let’s start with the basics in plain English: What are passkeys?

Tim Nash: Okay, so let’s start with what a passkey represents, because we’ve got passwords. A passkey is meant to replace or work alongside a password. So if you imagine your WordPress website, you go in and log in, and the usual way you log in is to go: username is Bob, password is password123, and then the website will authenticate you. It will go into its database, look at its passwords, do some hashing, come back and go, “Yay, hi Bob, come on in,” or “No, Bob, I don’t like you.”

There are a multitude of problems with passwords. The biggest one being that it relies on users knowing something. A password is something you know. It’s a secret that only you, and haveibeenpwned.com know. And if you forget that secret, we have to have mechanisms for you to recover and create new passwords. If your secret gets shared, it’s no longer a secret and your password is being spread across the internet. Your secret also has to be stored somewhere to be compared against. We hash those, so in theory, it’s not stored in plain text, but your password is being stored in a database somewhere.

Because of all the problems we have with passwords, we’ve implemented things like two-factor authentication, adding a second factor. So we’ve gone from something you know, to something you own or something you can trigger. This gets around a couple of the bigger problems with passwords, like phishing attempts, because the phishing attempt has to both take your password and then somehow act as a man-in-the-middle.

Passkeys is a system designed to get rid of a lot of these complexities. On the surface it looks like it’s just replacing the second factor, instead of your password. The truth is, it’s way more complicated than that.

If you were a user logging into a site, you’d go through a process flow to register, or log in your usual way, and then you’d be prompted: “Would you like to set up a passkey?” 

Now, quite often this is something that’s just thrown at users. One of the problems with passkey adoption is that it’s often you’re thrown into this flow, “Hi, would you like to add a passkey to your website?”, and you’re like, “No, Amazon, I don’t! What are you talking about?”

Here’s how it actually works. You have the relying party, the website that’s trying to authenticate you. This is normally the website, though it could be a third-party authenticator, like Auth0 or similar. It will say, “Okay, I’d like to log you in, Bob. I have some public keys here. I’m going to send you a token, and that token is going to have the ID of my domain – my website.” 

This ID is important because it means a second website can’t send the same token; you’d go, “But you’re not that website, so I’m going to ignore you.” That almost stops phishing straight away.

We pass that token to the client. The client is not you – the client is your browser. But you might have multiple clients. The client then talks to its authenticator. The authenticator might be something on-device, something in the cloud, Windows Hello, Bitwarden, 1Password, or Google. 

That generates an ID and a public and private key. We sign our token and send it back to the client, who sends it back to the relying party, and then we do this shuffle a couple more times, and eventually it lets us in.

Ultimately, that sounds really complicated, but it is just public key cryptography, the same thing that powers SSL certificates or your SSH connections. We’ve just added an extra layer. There’s a FIDO2 standard and the WebAuthn standard for implementing almost a UI to this public key cryptography that’s hiding underneath.

Robert Abela: Quick question. When you’re trying to authenticate, the website sends you its public key with its unique ID. Can someone just get the public key and ID and spoof it?

Tim Nash: No. The public and private key are held by the client and the authenticator. The public key that’s passed backwards and forwards is the public key of that client, and it’s generated for that one token, for that one session. So it only exists for that time. The next time you visit the website, the relying party will pass you a new public key for that interaction, for that session.

This is where it gets a bit more complicated, though. Each client has to be authenticated. If I’m on my phone and on my laptop, those both have separate clients. And each browser on my laptop is a different client. So each needs to be authenticated through a passkey.

We have effectively three options:

1. Device passkeys: physical hardware tokens like YubiKeys. The authenticator and private key is stored on that physical hardware. You tap it on the back of your phone or plug it in.
2. On-device passkeys: the authenticator is on that singular device and the private key never leaves that device. The downside: if you lose the device, you can no longer log into anything. This is very similar to the old Google Authenticator problem: if you lost your phone, you were locked out.
3. Synced authenticators: the private key is held somewhere in the cloud and synced between your devices. Apple’s ecosystem is a good example. When you’re on an iPhone and it pops up saying “do you want to use your passkey,” that is actually being stored in iCloud and synced between your devices, so your login on Safari on your laptop would work as well as Safari on your iPhone. You can also use services like 1Password and Bitwarden for this.

The downside to synced password systems is that if someone gets into your synced system, they now have keys to the castle. And there’s almost no way of tracking it, because these tools tend not to have amazing logging.

So, it’s a bit of a mess of an ecosystem at the moment. When people say passkeys are going to replace passwords, there’s probably a lot of truth in that. But right now, the two major problems with adoption are: first, it takes ten minutes to explain what they are, even to technical people; and second, how we manage passkeys if we lose one. Most sites will offer over one passkey, or some sites allow multiple, but this is often a paid add-on. And the solution when you lose access is usually a password. 

Robert Abela: So, if you don’t have a centralized system like iCloud, and you have multiple devices (mobile, laptop, tablet), can you have multiple different passkeys for the same website?

Tim Nash: The specification says yes. The implementation depends entirely on how it’s been implemented on the website. There’s nothing to stop that happening. A good example is Melapress’s own setup. On the free plan, you get one passkey, but on the paid plans, you can add multiple passkeys, so you can add multiple devices, 10, 15, 20 devices, and keep adding to them.

Behind the scenes, passkeys are smart about this. You’re maintaining just a list of public keys, so it’s not really that hard to implement multiple passkeys per site. You don’t lose any security, other than there being multiple devices out there that, in theory, could connect as that user.

To prevent misuse, passkeys are meant to work alongside the authentication methods provided by the authenticator, things like biometrics: face recognition, thumbprint, or a PIN. The reason so many people jumped on synced passkeys (Apple, Google, 1Password) is that managing lots of separate clients gets complicated. But that means we’re giving these large corporations all our data and passkeys.

There’s an argument that it’s probably better having one of these organisations store your passkey than storing your password, which has a much more obvious paper trail. But either way, we’re still potentially centralising things. And you can mix and match: for example, have a synced passkey system for most things, but for your bank passkey, put it on just one or two devices. The risk there is that the more sensitive it is, the more tempting it is to put it on a single device, and the more likely you are to lose said device.

Robert Abela: You mentioned some services limit users to one passkey only. Is there a security reason for that?

Tim Nash: Ultimately, if you have multiple clients connecting in, you have multiple ingress points and multiple threat areas. The old-school thinking is: if I only have to worry about one login from one client and one device, that’s simpler. But that’s a very old-school way of looking at it, because a passkey is ethereal; it’s not meant to be in replacement of a session. 

You don’t log your passkeys out regularly and rotate them. Once it’s set, the public and private key combination should remain in place. You wouldn’t change a passkey every three months.

So there aren’t really that many reasons not have multiple passkeys. It’s more to do with the end user’s personal security; the logic being, if I let them have five passkeys across five devices, there are five devices floating in the world that need to be secured. But that viewpoint sounds great right up until it gets stolen and they have to do a support query to fix it.

Robert Abela: You also mentioned storing all passkeys in one place. Isn’t that a danger as well? If your Google account is hacked, for example, and you’re storing them on Google, all your accounts are hacked?

Tim Nash: Yes. And all of these, it’s not like there is one magical solution that fixes this. Your 1Password vault is only as secure as the master password or biometric setup protecting it. But ultimately, all of these services still rely back on passwords. If you go into iCloud, it still wants your Apple password. If you go into 1Password, you’re still going to need your master password. Even if you’ve got Passkey set up, you can still bypass and go back to using your master password to get into these services. So it’s only as good as that master password in the first place.

These are also huge targets. A synchronised passkey manager, whether Apple, 1Password, Bitwarden, they’re all enormous targets. They’ve also got incredibly good security teams working for them, but you are putting those eggs in a very public basket floating up in the world.

There are some ways around this. Bitwarden has an open-source server implementation called Vaultwarden. But that requires quite a lot of technical setup, and now you’re having to manage your own password infrastructure. As somebody who spends a lot of time advocating to developers that they shouldn’t build their own security devices, the idea of someone standing up their entire password management setup on their own network frightens me unless they know what they’re doing. You’ve got to put your trust somewhere.

Robert Abela: I’ve seen that issue with 2FA too. Services like 1Password store both credentials and 2FA. So if your 1Password account is hacked, 2FA is rendered useless in the same way, right?

Tim Nash: Exactly. The worst case scenario is the person who says: “I’ve set everything up perfectly, just as you asked me to. My password’s in a password manager. Brilliant. My 2FA’s in the same password manager. Great. My backup codes are in the same password manager in the secure note.” Right. Now you’ve just created one point of failure.

But you can split these out. I do use passkeys, and my passkeys and my passwords are in two separate systems, more to do with history than an actual deliberate choice, but I’m pleased with it. Bitwarden didn’t support passkeys when I started, so I’m using one solution for passkeys and one for passwords. My master password for Bitwarden isn’t stored in Bitwarden; it’s in a separate, simpler password manager I can take offline.

It’s about getting the balance right. From an end user’s perspective, passkeys are magic, and they just work 90% of the time. The transparent process at the top looks really simple. All the handshakes and complexity underneath aren’t seen by end users at all. When you’re using a third-party service or a plugin, it just works. And when that happens, it feels like a much smoother experience.

Living in a world where we need to make passwords more complicated, rotate them more quickly, make them longer, and keep them unique, we need to find another solution, but we need to bring users with us. The big thing we’ve learned from two-factor is how difficult it is to get users to come along. Anything that makes their lives harder, they’ll say no to. Which is why passkeys are increasingly leading to “please sign in with Google” or “please sign in with Apple”, single sign-on. Most people’s first implementation of passkeys will actually be through their single sign-on flows. It will come to WordPress as a secondary phase, unless you’re willing to put it in yourselves using plugins like Melapress’s.

Robert Abela: For those who are not familiar, single sign-on is like authentication services like Google provides, with the same account. Once you authenticate against Google, other websites that support SSO via Google let you log in once you’re authenticated. Right?

Tim Nash: Yeah, and behind the scenes, instead of you getting the passkey prompt coming up straight away, you’d click on “sign in with your single sign-on,” and it goes through the regular flow you’re used to. So if it’s Google, a Google screen comes up saying “please authenticate to this site”; it looks like the normal Google login process. It will just say: “You’re going to log into example.com, is that what you want to do?” You say yes, and then Google tells the website, “This is Tim. Tim comes with these permissions and grants. Let him be on your site.” And the site goes: “Great. Welcome, Tim. I have a user for you already. Here you go, you’re logged in.”

That flow feels so natural to people because it’s what they’re used to. And that’s a similar thing you want to capture with a UX for passkeys, something so recognisable and simple that they go, “Oh, I know how to do this. And it doesn’t matter what site I’m on, I know how this flow works.” Once you’ve chosen your passkey route, the UI is defined by the client and authenticator, not by the website. So the process looks the same all the way through.

Robert Abela: Do you think the process of implementing passkeys is, at the moment, hindering the must-use of passkeys? Because if you’re the average user who just clicks yes to everything, it’ll probably work. But if you want some sort of control, storing passkeys in a specific place, it’s still too much even for a technical user. Do you see a way for the industry to make this easier?

Tim Nash: There are a couple of things. Because of how it’s all implemented, it’s still a bunch of diverse and separate companies, each with its own implementation of how it works. Apple does not want to make it easy for you to use somebody other than Apple for passkeys. Even 1Password and Bitwarden don’t make it a simple primary option; they make it feel like an extra step.

I think that will change over time. At the moment, because there isn’t a standardised UX across all things, there’s a standardised UX per website. Once you’re in the passkey flow, it’s the same each time, but different authenticators use different mechanisms. Over time, technology coalesces into one or two design patterns for these types of flows. I expect that will happen over the next couple of years.

A good example of the current friction: every time I want to store my passkey somewhere else, I have to remember to go to the dropdown and tick the correct location. That’s irritating. But that’s an issue with the authenticator I’m using, not necessarily a design flaw in the standard. WebAuthn or FIDO don’t actually say anything about the UX. I think it’s just “go for it.”

Robert Abela: Yeah, Apple, Google, Chrome, Microsoft all have very different interfaces. And from a different device, you might get a completely different experience, which can overwhelm the user.

Tim Nash: And that’s because with multiple devices, you can have multiple flows. If you’ve got a Google Chromebook and log in through Google’s system, but your personal iPhone is using Apple’s, those look remarkably different, the biometrics they ask for, the number of hoops. The website itself, the relying party, can specify a minimum level: “I’d like you to always check for biometrics every time we talk.” Or it can leave it to the authenticator’s discretion. The authenticators also have very different levels of paranoia and security attached to them.

Robert Abela: That brings me to the next question: Do you need any specific hardware to generate passkeys? I’m presuming most modern devices support it, but are there any limitations?

Tim Nash: If you’re doing a physical device like a YubiKey, you obviously need the device. For individual authenticators, there will be certain ones you can’t use in certain scenarios. I don’t think, for example, that you can use Apple’s iCloud authenticator in your Windows system; it requires the biometric side of things, which is built into Apple devices, and the way it stores the private key is tied to those devices. That wouldn’t work the same way on Windows.

Windows Hello weirdly doesn’t work on Apple devices. To use Windows Hello, I believe you need a TPM chip in your computer. That limits you to newer hardware. If you’re running Windows 11, you can absolutely use Hello. If you’re running Windows 10, you’ve probably been prompted to stop running it by now. I think it reached the end of life about a year ago.

Linux systems have a harder time with some of this stuff. Linux users tend to ask, “What about us?” and you’re being pushed more and more towards third parties like Google, 1Password, and similar.

Robert Abela: With all these complexities, do you see it being practical for WordPress agencies, say with 100 clients and 100 websites, to use passkeys, where the agency has passkeys to access client websites, and clients have passkeys on their admin accounts? Is it manageable?

Tim Nash: It absolutely is. When you get to a certain stage, your first five websites, you’re willing to create passwords for every member of staff. After that, you start reaching a stage where it’s getting harder to manage. If Joe leaves the company, you need to wipe out Joe’s accounts in multiple places. You need to make sure Joe’s changing their passwords when they’re compromised. You start reaching for password managers and larger tool sets.

Passkeys can work really well in this context because rotating and stopping a passkey is as simple as destroying the private key. The passkey doesn’t work anymore. So you can rotate from either side.

They’re also a nice one-to-one relation, especially with a device-based passkey. You can’t share it with Joe. So you can’t have a shared login unless you’re sharing the computer, which is actually a nice safeguard. Though that all changes with synced passkeys. Joe could share passkeys inside his enterprise environment; you could have 1Password running as a business, passkeys stored in there, and you can delegate access to members of staff temporarily.

The nice thing in that scenario is that passkeys have to be signed routinely. If they’re stored in a shared setup, you can delegate access just for a while. Joe can be given that passkey only while he’s operating on website B, and then he loses access.

That said, when you’re at that stage, you’re probably also thinking: Is single sign-on a better solution for us? Give clients their normal logins, but we, as the agency, log in via our single sign-on solution. Both bring complexity, but passkeys are actually simpler to implement on a per-site basis than a full single sign-on solution in most cases.

Robert Abela: Of course, if a laptop is stolen, you can easily delete the key from the system, right?

Tim Nash: Yeah, you really do want to sync in that scenario. You’d be looking at synced passkeys via a centralised passkey management solution like 1Password. You’re probably using a passkey to access that vault in the first place. It only really comes into its own if you’re then managing delegation properly. The beautiful thing is you can give somebody temporary access to a passkey. Even if they have the key afterwards, if they can’t generate tokens, that doesn’t matter. The private key is always stored on the authenticator, not on the client. So the authenticator can say, “Your client is no longer accepted. I’m not going to sign that token for you.” Which makes this a much nicer solution.

Robert Abela: Are passkeys mainly designed to replace passwords? Or do they offer other benefits beyond that? And are there things beyond what passkeys store in a website database?

Tim Nash: Passkeys were always brought up as the password replacement. There have been attempts to redefine them, but it always comes back to the same argument: they’re there to try and replace a password. But that is the WebAuthn level of passkeys. Underneath that is a whole wider specification.

The FIDO2 specification for device management is exactly that; it’s talking about wider device management across the board. It’s designed to be flexible enough to get its tentacles in all sorts of places wherever you might need authentication: inside SSH processes, alongside VPN credentials, things like Tailscale, experimenting with passkeys. Whether or not those will succeed is partly down to how adoption goes for just replacing passwords.

At the moment, passkeys are not getting adopted widely. They’re gaining momentum, but there isn’t enough information about them. If you search for passkeys on YouTube, every video starts with someone saying, “I’m going to take a deep breath and explain this to you,” and at no point does anyone think this is going to be an easy sell. Because we’re still at that stage, trying to sell any other benefits is pointless. We’re still trying to sell the primary benefit, which is supposedly that it’s easier to use, which it is. It’s just not easy to implement.

If we can convince users to actually read the prompt and not just click yes, yes, yes, oh my God what was that, no, we need to get them to at least flow through so they can use them the first time. Once you’re using them a couple of times, it’s like, “Oh, actually, this might be useful.”

With so much terminology that doesn’t match through, the “relying party”,  what’s that? 

Oh, it’s a website. It doesn’t sound like it. It sounds like some sort of weird group. Ultimately, we’re talking about the equivalent of a train ticket being stamped by the train guard, where the stamp is a bit more sophisticated than a hole punch. But until we can get that explained and people start using it, we can’t really explore much further.

And it’s not just non-technical people. Technical people aren’t using passkeys at all. It’s really hard to convince them. One reason is they want more control; they don’t want to use Apple’s implementation, which is simple and nice, because they want to control where the passkey goes. But the version where they have more control has garbage UX and requires 28 steps to get it to work.

We’ve spent nearly 20 years teaching people to use password managers to the point that it’s easier to use a password manager than to remember a password. It’s now quite difficult to retrospectively say, “But we found an even easier way, you just have to tick these six boxes.” 

The simpler implementations will win out. I suspect we’ll see passkey adoption in non-technical users before technical users. But as technical users, we need to sell the benefits to non-technical users, even if we don’t use passkeys ourselves.

Robert Abela: Do you see website authentication without passwords, is it possible, or not yet?

Tim Nash: I think so. I, as an experiment a couple of years ago, removed passwords from WordPress entirely. I just got rid of them and used a combination of a magic link system, it sent you an email, and when you came back through, it then asked for a second factor and let you in. That was three to four years ago.

Passkeys can definitely work, but you do need a backup tool. Because, as the website, you don’t control where the authenticator is. You can’t say, “I’d like you to use a non-device-only passkey.” You’ve got to work with the assumption that the passkey has been generated on the device, and that is the only existing place for it. You can’t force it to be a synced passkey. So you need a backup solution, and that backup solution has to be better than a password.

Could we use passkeys combined with magic links to reset and regenerate a new passkey? 

That’s a possibility. Could we use fingerprinting combined with those techniques? Absolutely. We could outsource the login flow completely through single sign-on. Or we could completely get rid of authentication altogether for some sites, like a typical WooCommerce site with guest logins. Why do those guest logins go through complicated loops? Would a passkey or magic link work as an alternative? It’s about working out what levels we want to aim at.

Robert Abela: That’s what I meant, because the biggest problem we see, even with 2FA is not people using 2FA, it’s the backup solution. People get locked out, they forgot their mobile. So, at the moment, it seems like passkeys without passwords, plus a magic link to reset, is still too complex for users to understand. I still don’t see a way for a website to work without a password, unless you have multiple admins with multiple passkeys. If you’re the only person and you lose your device, you’re locked out unless you have a backup mechanism.

Tim Nash: Yeah, if you’re the only administrator of a site, let’s take my personal website as an example. I could absolutely run that without a password, just passkeys only, delete and remove the password functionality. Worst-case scenario, if everything goes horribly wrong, I can just go into the database and give myself a password. Or I can regain access that way. So if everything went horribly wrong, that’s fine.

It doesn’t scale, though. That works for me, for you, for maybe a company the size of Melapress.

Robert Abela: That’s because you are technical. The average user, even I see it in support emails, if you say “go to the database,” good luck.

Tim Nash: Exactly. And even for technical setups, it doesn’t scale to 100 or 150 employees. At a 100-person company, I remember dealing with level-one tech support, and there was a tech support person whose full-time job was resetting passwords in various locations and clearing the printer spool. Once you’re at 100–150 people, you’re going to spend your entire life resetting passkeys. Get to 200, 300, even with a technical person, it won’t work.

For a mom-and-pop shop, it absolutely won’t work. If they can’t do the thing straight away, they’re locked out, and they’re going to have to pay somebody. They’ll go to their hosting company, which will say, “No, we’re washing our hands of this.” So they’ll have to hire somebody, and that’s not sustainable. They’ll quickly say, “I don’t want passkeys anymore. I want a password back because I understood a password.”

And a passkey is ultimately a text file with a vast quantity of characters. You can’t store it physically on paper and retype it.

Robert Abela: Now, as soon as you mentioned that I should try it, print it out!

Tim Nash: Yeah, an old dot matrix printer, and you could just process it through the scanner!

Robert Abela: So, at the moment, wherever you see passkeys, in most cases, especially in WordPress, you still see both passkeys and passwords allowed. Does that render passkeys less useful? Even if you’re using passkeys, should users still use strong passwords? Because it’s still possible your passwords can be guessed, stolen, or leaked.

Tim Nash: Yeah. Your password is still as at risk as it was before. Bad actors can still brute force it. If passwords are leaked, they’re still leaked, they still exist, and obviously, they can be used.

Worst case is you’re probably not thinking about those passwords. So when you use the same password on 20 sites, which you absolutely shouldn’t have done, but you did anyway because you’re a human being, and then you put passkeys on 10 of those sites, you’ve forgotten you had a password on 10 of those sites. Then you find out your password is in a database somewhere. You go and change it on the 10 sites you know about and use, but leave it as is on the other 10. The bad actor just gets in that way. Your password is still just as important.

Similarly with phishing attacks. One of the major benefits of passkeys is to stop phishing; the idea is that you should not be able to be phished using a passkey. But the reality is the bad actor just creates a site and says, “What’s your password?” And you go, “That’s weird, my passkey didn’t come up… oh well, I’ll type in my password anyway.” Completely. So until it’s unusual for passkeys not to show up, phishing attacks will still succeed quite successfully.

So we must keep maintaining passwords, and that means if you have a password, you need two-factor attached to it. This leads to a really awkward situation where, for the foreseeable future, we’re going to have passkeys (yay, they work brilliantly), and also passwords (yay, I know how this works), and I need my two-factor. So all the pain we’re saying we’re getting rid of, you still have to have, you just don’t get to see it as often. And the temptation will then be to merge your passkeys with your password into a single point of failure. And then that gets compromised, and you’re screwed.

Robert Abela: So even if you use passkeys as your authentication, if you drop passwords, is it still recommended to use 2FA as well? Or are passkeys strong enough?

Tim Nash: Passkeys are meant to be strong enough. If you think about what 2FA is, a password is something you know, a secret. And the other 2FA factor is something you own normally, whether that’s proving you own an email address, a phone, or a text message endpoint. You’re authenticating through something you own.

Passkeys already sort of live in that second category. The authenticator is doing the proving-who-you-are part, albeit that your “secret” is your face or thumbprint, which isn’t that secret if you think about it. So we’ve already got that secondary factor. What we’d be doing by adding 2FA is providing another variation of something we own. And if we’re sending that to the same client, what was the point?

As the website is doing this, we don’t know where the second factor is going. We don’t know if the client and authenticator are on the same device. So it’s either an extra layer that is actually useful, or it’s a pointless waste of time, that we’re pushing to the same potentially-compromised thing.

Personally, I haven’t been implementing a second factor with passkeys. But I can see a case where I would, if I had two devices in play and if I were using hardware tokens with my passkeys. The authenticator may also already use two-factor. If you go through Google’s flow, it might say, “I’ve got you logged in via biometrics, but I’d also like you to log into your phone and open the YouTube app to prove it’s you.” Or Apple going, “We’ve sent a message to your iPad”, and you’re like, “But my phone is in my hand!”; “Yeah, but we sent it to your iPad because that’s the second factor, and it’s a different device.” They’re already doing a lot of the two-factor stuff for you. In those scenarios, you don’t want to add yet another factor. We’re trying to make this flow easier, not more oppressive.

However, as long as you allow password logins and aren’t exclusively using passkeys, then yes, use very, very strong passwords and enable 2FA. If you’re using passwords, you should be enabling 2FA. I can’t actually think of a scenario where that wouldn’t be my standard advice. A password alone is not enough. You need that second factor in place.

Robert Abela: So, for anyone trying to sell passkeys, a lot of website owners will say, “Passwords work fine, why should I change?” What’s your honest answer in favour of passkeys?

Tim Nash: Ultimately, the end user is going to start expecting it. Amazon is starting to push passkeys heavily. Apple, all the big vendors are pushing towards passkeys. It will start feeling weird to not be implementing passkeys. So you’re better off getting ahead of that curve.

The other reason is that if you run a business and have employees, you want passkeys for the anti-phishing techniques. You want that reliability. And ultimately, passkeys give you finer-grained control; you can delegate access in more granular ways.

Passkeys are ultimately more secure. And they’re designed to be secure. Passwords weren’t really designed with any level of security as a protocol; there isn’t one. It’s just: you hand over some secret information and hope it’s stored correctly. Passkeys are developed in a way that works to a specific standard, in a specific way, and implementation should be identical across the board.

Would that have sold it to the end user? I’m not sure. Because they’d still go, “That sounds wonderful, when do I get rid of my password?” And I’m afraid at that point I go, “Yeah… let’s talk about that next year.”

Robert Abela: So, what should the average WordPress website owner do within the next 24 hours to get started with passkeys? Do you recommend any resources?

Tim Nash: There are some really good resources. For a more mid-level explanation, there’s a YouTube channel called Computerphile, which goes through all sorts of various bits and pieces. About a month ago, they did a video on passkeys, which I’d recommend; it gives a high-level overview, similar to what we’ve talked about today.

If you’re doing it on WordPress, Melapress has a plugin. Use Melapress; it’s part of the 2FA plugin, so you can go and play with it today. You can set up passkeys independently of enabling the 2FA aspects, as well as inside that. There are other WordPress plugins out there that support WebAuthn, but I haven’t found any I particularly like in how they’ve implemented it.

Go experiment on test sites, not production. This is something to roll out over time.

If you want to see how passkeys actually work, chances are you have an Amazon account. Log in, and if you haven’t already, you’ll probably be prompted to upgrade to a passkey if you’re on a device that automatically supports it. You can start looking at the flows there. Just remember: once you’re enrolling something on a passkey, you’re actually enrolling something, so don’t store things to a device just as a test and then find out in six months you can’t remember which device you stored it to.

Robert Abela: Yeah, I know people who actually lost bitcoins because they lost the device where they had their wallets! And it’s important to point out, this is not just some WordPress hobby stuff. Passkeys are supported and backed, and are being effectively developed by big tech companies: Apple, Google, Microsoft, and Amazon. Does Facebook have passkeys?

Tim Nash: I do not know. I’ll be honest, I haven’t logged into a Meta property in quite a while, so why wouldn’t I say good?

Robert Abela: Okay! That’s it for now, we definitely have more questions we can discuss in another episode. Thank you very much for your time, Tim. Can you tell everyone where people can find you and anything coming up?

Tim Nash: You can find me in all the usual corners of the internet. Primarily these days, you can find me on my own website, timnash.co.uk, and then we’ve got wpsecurity101.com, which is our online security course. Or you can find me on LinkedIn, just /in/tnash.

As for what’s coming up, I am busily recording a new module for WP Security 101 on agentic coding and how to make your vibe coding actually vaguely secure.

Robert Abela: Nice! It is a course I recommend. I’ve seen some parts of it and the table of contents. It has some very interesting topics, and what I like is that it offers practical tips for the average user. You don’t have to be a security expert to follow it. Even if you have a website or two, I’d definitely recommend taking a look. Because, as you said, user knowledge will always be the most important key of the whole chain.

Tim Nash: Yes. We need to encourage people to take practical steps. When it comes to security, it’s easy to say, “Oh, it’s too hard,” and do nothing. Anything I can do to break that barrier down and make people go, “Oh, I can try that”, on the whole, is a good thing. If we can just improve things just a little bit each time, we’re going to be in a good place.

Robert Abela: Good. Thanks a lot, Tim. Thanks everyone for joining us. Don’t forget to like and subscribe so you’re notified of future episodes, which we do weekly. Hopefully, we’ll see you next week. Thanks, Tim. Thanks everyone. Bye!

Tim Nash: Thanks!