Next-Gen Account Security with Christiaan Brand

“It is important to always think in the back of your mind, how we can bring usability into things.” - Christiaan Brand Share on X

With phishing and password breaches on the rise, passkeys could offer a more secure, user-friendly solution that could reshape how we protect our online identities. Today's guest is Christiaan Brand. Christiaan is the co-founder of Entersekt, a financial services security firm and a key player at Google in their security and identity teams.

A respected voice in cybersecurity, Christian co-chairs the FIDO2 technical working group focusing on standardizing robust online security protocols in advancing the use of passkeys. He has been at the forefront of the shift toward more secure, password-free systems. We’ll hear his insights on the challenges and opportunities of implementing passkeys to create safer online environments for users and organizations.

“I was focused on trying to figure out how we make sure that users accessing their financial information, so from a banking perspective, can do that in a safe and secure way.” - Christiaan Brand Share on X

Show Notes:

• [00:52] – Christiaan is part of the security team for Google accounts. He's been with Google for 9 years. Prior to that he had a startup.
• [01:30] – He joined the FIDO Alliance around the same time Google joined in 2013. When he joined Google, he was able to continue with the same type of work.
• [02:35] – Each of the big tech companies represents a portion of the market when it comes to how we interact with the web and apps.
• [04:06] – He became interested in security when he started thinking about what could go wrong with new technology solutions. He wanted users to be able to access their financial information in a safe and secure way.
• [05:06] – 2FA began gaining traction with Google in 2011. It coincided with the launch of Google Authenticator. 2FA was also used by a gaming company.
• [07:54] – Usability is important, that's why having an app that displays the codes was one of the first forays into making the technology more accessible.
• [08:34] – Passkeys allow us to move beyond passwords, leaving the extra hassle of traditional multi-factor authentication behind.
• [11:05] – Key fobs were one of the earlier ways to try and bring usability to security. Now the technology is being moved to smartphones.
• [12:33] – Passkeys are a replacement for a password manager.
• [13:35] – Passkeys are extremely long and asymmetric in nature. You and the site you're going to both have the passkey.
• [14:27] – The service will have the public part of the passkey, and you'll have the private part. Even if the public part leaks out, your passkey will still be secure. Passkeys can never be revealed to phishing sites.
• [15:47] – FIDO brings the second authentication step in. The service also has to identify themselves.
• [20:04] – Password managers try to balance security and convenience. Logging in or accessing a passkey is a unique challenge for providers.
• [22:20] – Phone numbers are a way to get users back into their accounts.
• [25:19] – Single device users have extra challenges.
• [26:08] – There are pros and cons to external sources of identity.
• [29:44] – The FIDO website has many certified solutions.
• [33:21] – To get passkeys into daily users' lives, we need to start using them on daily applications where we log in frequently.
• [35:49] – Hopefully this passkey solution will stand the test of time.
• [37:34] – Attacks are beginning to shift to session hijacking.
• [38:24] – DBSC or device-based session credentials is a new standard parallel to FIDO.

Next-Gen Account Security with Christiaan Brand Share on X

Thanks for joining us on Easy Prey. Be sure to subscribe to our podcast on iTunes and leave a nice review. 

Links and Resources:

• Podcast Web Page
• Facebook Page
• whatismyipaddress.com
• Easy Prey on Instagram
• Easy Prey on Twitter
• Easy Prey on LinkedIn
• Easy Prey on YouTube
• Easy Prey on Pinterest
• Entersekt
• Christiaan Brand on LinkedIn
• Christiaan Brand on Twitter
• Christiaan Brand on Facebook
• FIDO2 Technical Working Group
• Learn More About Passkeys
• Passkeys.Dev
• FIDO Alliance Passkeys

Transcript:

Christiaan, thank you so much for coming on The Easy Prey Podcast today.

Thank you so much. Happy to be here.

I'm glad you're here. Can you give the audience some background about who you are and what you do?

Happy to, yeah. I'm Christiaan Brand. I am part of the team that looks after security for Google accounts here at Google. I've been with Google for a little bit over nine years right now. Before that, I had a startup company; everything in the same space. We've been working, and I've been working on phishing-resistant, strong authentication for a long time. With the FIDO Alliance starting, I recall correctly, around about 2013, that was when I was still at my startup company. We joined the FIDO Alliance. That's about the same time that Google joined the FIDO Alliance.

When I moved on from my startup and joined Google, I had the opportunity to continue on the same vein, to continue in that same area. I'm representing Google in the FIDO Alliance, where today, I hold the position or volunteer position of the co-chair of the FIDO2 Technical Working Group. I would say that's the first of the three hats that I wear when we think about this work.

I'm co-chair of the FIDO2 Technical Working Group. That is inside of the FIDO Alliance, where we work on standards. We try to think—tech companies and other major vendors—what do they need to put in place in their products to ensure that we can all have safety online? That's step number one.

Step number two, within each of the companies, Google is represented, of course, in the FIDO Alliance. Microsoft is represented. Apple is represented. A bunch of other companies, too. Each of our companies represent a portion of the market when it comes to how we interact with the web and interact with hacks. At Google, we have two major platforms. We’ve got Chrome and we've got Android. Taking these standards that we are developing inside of FIDO Alliance, and bringing that into our respective companies to get that implemented in our own products. In our own platforms, I play a liaison role in getting that implemented.

Lastly, I want to say for the last maybe two, three years, once that has happened and we now have support for all these cool standards inside of our products, inside of Chrome, inside of Android, inside of Edge, inside of Safari, iOS, and MacOS, because of the work that Apple's been doing and Microsoft, now we're starting to think about, “How do we take the technology and expose it to our own user base?” I have a hand in that as well. I'd say that my third hat—figuring out how to take all this cool technology and then bring it to the billions of Google users out there.

I love it. What got you interested in account security?

That's a great question. If you think about technology and bringing that level of information out to users, very quickly, I don't say go over to the dark side, but you start to figure out, “All right, what are all the things that can go wrong?” Back in 2007-2008, the company that I co-founded was around. Now that we start seeing smartphones loom on the horizon, how do we make sure that information is adequately protected and provided safely and securely?

At that point in time, we're already starting to realize, as an industry, that passwords is not good enough to protect information. Two-factor authentication was the thing that were just starting to get a little bit more traction in various companies. I believe that's around the same time that Google started looking into two-factor authentication or two-step verification, as we call it. I was focused on trying to figure out, “How do we make sure that users are accessing their financial information?” From a banking perspective, we can do that in a safe and secure way. That's really what got me into this space, more of the financial from the banking side. As time went on, I started expanding more into the general consumer market as well.

Got you. I'm trying to recall here. Maybe you can help me. Where did 2FA originally start gaining traction as far as actual customer-facing implementation?

I probably should have done my homework better here, but I believe that Google was one of the—if not the first company back in 2011, if I recall correctly. That's before my tenure at Google; I joined in 2015.

Roundabout there was when I think Google was one of the first consumer services. I believe if I remember the history correctly, there was actually one gaming company that was really the first. It was one of these online player game situations. I guess they had real challenges with passwords being compromised. I can't remember the exact reasoning, whether it was remote server-side breaches or whether people were getting phished. Phishing has been with us for many years, so probably that. But I think they were the first.

A couple of months later, I believe Google came on the scene as well. Like I said, it predates me a little bit, but that was the start essentially of multi-factor authentication. In Google's case, it coincided with the launch of Google Authenticator, a product which I now work on as my day job at Google as well. I'm very proud of the functionality that we launched just about a year ago now to finally take Google Authenticator and back those codes up to the cloud in some way.

A lot of the issues that we heard from users were, “Hey, I got a new phone; where's my codes?” It is important to always think in the back of your mind, “How do we bring usability into these things as well?” Actually, we had a lot of pushback back when we started to say, “OK, maybe we should back up these codes and make it easier for users.” A lot of security purists said, “That's a bad idea. How can you imagine even doing something like that? What if my Google account gets compromised?”

There's always a balance and always a tradeoff. I think on a whole, we are now making multi-factor authentication accessible to more users because of these ease-of-use arguments. I want to rewind a little bit back to the start of multi-factor as well. That's essentially what we did there too. Back when multi-factor authentication existed for a while, we had lots of companies in the space.

RSA Security is a very popular company. They made fobs that displayed one-time codes. Not very usable, if you think about it. If we wanted to bring that to consumers, through Google's lens at least, was, “OK, we should make an app that you can download to your smartphone that will essentially put these tokens directly in the hands of the user.” That was our first foray into making the technology more accessible.

We've got a whole bunch of users over the years using that, and then we've added additional factors over time. SMS became a big factor. You don't need any apps for that. It's not just pros and cons, but SMS is one. Google Prompt is another technology that we added over the years, where we send push notifications to users' phones. That's incidentally also a technology that my previous company were very involved in. That's the technology we brought to the banking space, push authentication.

What I think I want to focus on a little bit more now going forward is passkeys. That's the fourth iteration, I want to say, of multi-factor authentication. The big difference with passkeys is, unlike traditional forms of multi-factor authentication, where it was a bandaid, it was something that you had to do on top of your password, with Passkeys, we can now finally sigh of relief like, “We don't need the password anymore; we can move to the Passkey and leave all the other crap behind.”

I'll back up and then we'll move forward. Probably my first 2FA was the PayPal key fob.

Interestingly enough, I think they called that technology security key, if I'm not mistaken, a term that then we re-coined for the physical fob, the security key for FIDO, and passkeys now. You're absolutely right. I think that was even before the 2011 launch date. if I'm not mistaken.

Yeah, I think so. I also remember, I've got a family member who lives overseas. In the country he was in, there was no SMS; it was all key fobs. The institutions primarily required them. I remember one time him pulling this bundle out of his pocket that was 10 or 15 key fobs. I'm like, “Oh, this is a horrible sight of the future that for every account I have, every banking institution, I'll need a cabinet to store all these silly key fobs.”

Absolutely. I can't exactly recall what we used to call them, but pre-passkeys on your phone, we were working on the technology. The first instantiation of the technology, of FIDO technology, was in these little fobs called securities. That was one of our big claim to fames or selling points was you can now have one to rule them all. Even though the institution required you to do a physical fob, the cool thing about these were they were segmented in a way that you are OK having all of your bank accounts, all of your social media, and whatever accounts, associated with the same fob because there's no correlation right between these services from a courtesy standpoint.

I think we used to call them the fob keychain problem or something. You have this picture of this diagram of this person with this keychain with 17 different sizes. It's ridiculous if you think about it, and that was our first. Again, we think back to it. It was a way to try and bring usability and use into it rather than purely from the security perspective.

Yeah. A single key fob makes sense, but it's definitely not scalable.

Absolutely, and I think we realized that. I was listening to another podcast. I can't recall exactly what it was, maybe a week or two ago, and I think there was this misnomer that, “Hey, FIDO got it wrong the first time.” They tried to get everyone to use hardware keys, and now we're finally at the point where we realize that's not working, now we're moving on to software on the devices. I don't think that is quite the right way to think about this problem. It's more that the easiest way to solve the problem was to take the technology, the phishing-resistant technology we had in FIDO and contract with a company, contract with a Yubico, FEITIAN, or any one of the companies building these hardware devices to very quickly and very rapidly build the technology into a device, which is very purposeful.

Something that we've always realized: You're not going to rule the world or win this by mandating that everyone carries around another piece of hardware. -Christiaan Brand Share on X

The security key, the little fob does one thing, and it does one thing very well. The intent was always once we have smartphones and other devices at a significant level of penetration, you start to move the technology there. It's a natural progression for us. Something that we've always realized: You're not going to rule the world or win this by mandating that everyone carries around another piece of hardware.

Let's talk about passkeys. What the heck are passkeys?

Great question. The simplest way to think about passkeys are that they are a replacement for your password or your password manager. When you deal with a password, I think everyone here probably listening has an idea of what a password does and how we work with passwords. You can either write your password down, you can try and remember it, or you can use a password manager on your system. More and more these days, we're trying to encourage users to use a password manager, because a password manager can ensure that you're using a complex password, you're using a unique password for every website, all good password hygiene things that we've been hearing from the experts for years.

The simplest way to think about passkeys are that they are a replacement for your password or your password manager. -Christiaan Brand Share on X

Passkeys are just like a password. The only difference is you cannot remember them and you cannot write them down. They're just too complicated to do that. Basically, if you have a password in a password manager, that's exactly what a passkey is. It's a password in a password manager. The only difference is the password is extremely long. The password is asymmetric in nature. What does that mean? It basically means, with a normal password, you have your password and the site you want to log into also has your password. They need to have it to validate it.

We can argue, purists will say they don't really have the password. Maybe they got [inaudible 00:13:46] attached to the password. It doesn't really matter. They've got the other side of the same thing. If they get breached, if someone breaches the database on their side, reversal and other stuff can happen, and someone can then figure out what your password at that other site was. If you reuse the password, then it means that they now have your password for other sites where you used the same password.

Passkeys are just like a password. The only difference is you cannot remember them and you cannot write them down. They're just too complicated to do that. Basically, if you have a password in a password manager, that's exactly… Share on X

Again, back to passkeys. Passkeys are different because they use asymmetric cryptography, which means you have a private part of the password; the service has the public side of the password. Even if the public piece leaks out, it cannot be used to authenticate or prove your identity to that system.

Passkeys work in a way where the passkey can never accidentally be revealed to a site that just looks like the real deal. -Christiaan Brand Share on X

I want to say three things about passkeys make them unique. (1) Like I said, is they're super long, so they're super complicated, and they have to be stored in a password manager because of that. (2) They're asymmetric in nature, which means server-side data breaches, we now shrug, we go, “Ah, man. Doesn't matter, because whatever gets revealed from the server side cannot be used to authenticate or prove your identity to the system. (3) Unlike with a password, where you can be tricked into entering your password on the wrong website, something that looks like Google, looks like Microsoft, but it's really a phishing website, looks like your bank, users can get tricked.

With passkeys, it's your job to prove your identity to the service, but it's also the service on the other end's job to prove their identity back to you. That is the key portion. -Christiaan Brand Share on X

Passkeys work in a way where the passkey can never accidentally be revealed to a site that just looks like the real deal. Passkeys, potentially if you think about it, and again, folks might argue about my simplistic representation here, but essentially, if you think about a password, it's your job to prove your identity to the service. With passkeys, it's your job to prove your identity to the service, but it's also the service on the other end's job to prove their identity back to you. That is the key portion.

Really, FIDO's whole reason for existence is bringing that second authentication step in as well to make sure that users are not getting phished. Again, phishing: number one problem that we deal with on a daily basis—still phishing. It's so easy to pull off. It's so easy for users to fall for it. Again, we've done research that shows for a well-crafted phishing page, over 40 percent of users when presented with a well-crafted phishing page will still fall for phishing today.

All of the emails, all of the notifications from banks and others saying, “Hey, users. Don't fall for phishing.” It doesn't work. We need to let the technology solve the problem for us. That's really what passkeys are all about.

The way with passkeys are implemented, and it also would help protect against a situation. That classic, someone has your password, but they want to get the 2FA code that’s sent to your phone, not with hacking your phone or anything like that, but by tricking you into revealing that second factor. This gets around that methodology.

Absolutely. There is no way to relay. That's a problem with passwords, that's a problem with SMSs, or that's the problem with authenticator codes. Someone can trick you into revealing that code to them. They can call you up.

We're seeing this in India at scale. India is very dependent on phone number-based authentication for various services. What we've seen happen at scale there is someone would call a user up and say, “Hey, I'm from the service you're just trying to access. You're going to get a code. You need to read that code to me.” The user reads the code. At that point in time, the whole system comes crashing down because you're supposed to keep these things safe and keep these things secret.

Again, we can try and teach this to users, but at some level, social engineering works. Phishing, number one problem. I want to say the very close second is probably social engineering, where users are being tricked into doing something that they shouldn't be doing, but we're trusting by nature.

Humans are trusting. If another human calls you up and says, “Hey, I need this code because I'm this authority figure from this service. You’ve been hacked, and I want to try and help you get your money back or whatever,” some percentage of users are going to fall for that. Passkeys get around that, not only by essentially eliminating the second step, but introducing a much stronger first step. In other words, the passkey authentication itself is much more secure in a way that cannot be relayed in calculation.

Got you. The drawback from SMS is that it can be socially engineered. You still have to have that phone number. Someone ports your phone number away, or you cancel your service, now you don't have access to that second factor. With the key fobs, you can lose the key fob. I know with the early authenticator-style apps, if your phone crashed or you lost your phone, the recovery process for those codes was arduous, difficult, and a disaster. Or if you just even wanted to switch over to a new phone, you've got to re-set up all of these things as if you had never done it before. How do passkeys address those types of issues?

Great question. If we think about passwords, passwords work well or have served us well in the past. How did this start out? Thirty years ago, we all had one password, we remember it in our heads, and that's what we typed everywhere. It doesn't matter if your machine breaks or you suddenly rock up an internet cafe. We don't use those anymore, but you did. You woke up and you just typed your password. Muscle memory, it works. It's a fine system.

Of course, we've moved on so far beyond that. You obviously cannot use a password anymore that you reuse across services. Probably if you use a password that you can remember in your mind, it's not complicated or complex enough, so most services won't even accept it. Those are already…even without passkey in place, we have to move to a new system.

The new system is maybe I write them down in my notebook, but then I can lose my notebook. I might not always have that with me, or I use a password manager. Password managers try to balance the security and the convenience, where it says, “Hey, I'm going to remember your passwords for you, not only on your current machine, but I'm going to put it somewhere in the cloud. If you come to a new machine, you get everything back.” That's exactly the same way passkeys work. You're going to get your passkeys back on your new device.

Any astute listener here would go like, “Well, but how do I get it back on my new device? How do I ensure that it's not an attacker that gets all my passkeys back on their device?” There is a bit of a chicken-egg issue here in the same way that there's a chicken-egg issue with a password manager.

How do I sign in to my password manager to get my passwords? My password to my password manager is saved in my password manager. There is a very unique challenge or opportunity here for the provider of passkeys on the various systems. If we think about who provides the passkey or password manager on the systems today, of course, Apple has their version—iCloud Keychain—or I think they're rebranding it. We have ours on Google called the Google Password Manager.

The Google password manager on Android is where we put all your passwords, and we also put all your passkeys there. They're secured with your Google account, which means that if you get a new Android phone and you want to sign into that Android phone and get all your passkeys back, first you need to get into your Google account. How will you get into your Google account if you don't have your passkey? That is the unique opportunity that the provider of the system has—the Apples, the Googles here, and the Microsofts have.

How are we going to get users into their accounts so that they can get all their passkeys to all their services back? There's a little bit challenging, interesting things happening currently in the world. In the EU, we're seeing a lot of interest and a lot of work being done on digital IDs. Maybe we'll all have our driver's license being digitized in a way that we can use that as a way to present our identity to a system and get access to our account back. Who knows? We're very early stages on it.

Another external way to sign into your account back to the SMS situation, phone numbers is a good way, which scales universally to get users back into their accounts. It has drawbacks. In most cases, if you get a new phone, at least in countries that I've been living in personally, you keep your number. You don't change your number. I know that's not always the case.

In some other countries or in some other geographies, when you get a new phone, they might just simply get a new phone number as well. That makes things a little bit more tricky. But if you keep your phone number, we can extract or tie some of the Google account identity to that phone number. It comes with cons, things like SIM swapping and other types of issues that we've seen there. But in general, our challenge as a root provider of the passkey system is ensuring that the user can get back to their account without the need for their passkey so that they can then get all their passkeys back.

I want to say that if you think about what are the future problems we need to now solve, that's a great problem that we now need to go and solve. For example, a Google account on an Apple device is great, because we just put the Google account passkey in iCloud Keychain. We say, “Apple, you figure out how to get their passkey back on the new phone.” Again, how do users move from one device to another? Again, more and more users have their old device handy when moving to their new device. By bringing these two in close proximity, that’s, of course, a great signal to say, “Yeah, this is the owner of both devices.”

In cases where your device is lost and your devices are stolen, those are tricky. We're trying to understand and figure out what are the external sources of identity we can rely on to ensure users are able to get their passkeys back? Signing into your bank or into your favorite service, your favorite social media account, or whatever on your phone is then as easy as just touching your fingerprint or showing your face once your passkey's been bootstrapped.

I guess the easier solutions are, at least many people in first-world countries have a phone, a tablet, a desktop, or a laptop. If they were able to lose one, there's one or two other devices to say, “Yes, I am who I claim to be. Reinstall over here.” I've seen that with Google in terms of, I try to log in on a different browser and it says, “Hey, go to your phone and open up this app and give us that number, or go to your tablet and do this.” There's already a little bit of that going on. But when countries where an individual may only have a phone, that definitely starts to become a challenge because, well, I don't have it anymore.

Absolutely. Developing markets are a challenge. If you think about it, we have lots of users who are what we call single-device users. They have access to exactly one device. If that device gets lost or stolen, or in some cases, users need to sell their old device before they have money to go and buy their next, that’s not something we like.

Here, you get your new phone and then you show back your old one. Very trusting. You'll show back your old one, you'll get a credit. That's how we think about the world. In many cases, that is not quite how things work.

Having a way you bootstrap your identity back into the ecosystem when you've lost everything else is not the exception; it is the rule in these places. That is why I'm saying relying on external source of identity like a phone number—phone numbers have their pros and their cons. They've got a lot of cons, but they've got some pros as well because in many of these countries, at least you take out the SIM card before you get your new phone.

Hey, if you think about the SIM card in a phone, more and more we're moving to it. It is challenging too. A lot of developing markets, physical SIMs are still a big deal there because they're such a good route of trust. Because you pull them out, you stick it into your new phone. If we could somehow leverage the fact that it's the same SIM card in the new device, it almost makes me think of the security key, or almost like your PayPal fob of the old days.

You've got a physical piece of hardware that is meant for security. Of course, the goal of the SIM card is just to give you access to the same phone number. But here, leveraging that allows us to have a data point that is the same user. Those are the types of things that we're now starting to invest in more and more. It's figuring out how do we leverage these external identity sources to make it easy to get access to your Google account, which then by definition means you get access to everything?

Got you. On the development side or the institutional side, is implementing passkeys an order of magnitude more complicated than SMS two-factor authentication or a token two-factor authentication?

They're definitely harder to do than passwords, because I think passwords are so simple if we think about it. Back in the olden days, we did a string comparer, then we said, “Well, that's not great to store people's passwords in plain text.” We started hashing them and solving them. I think for passwords, you can pretty easily build everything from scratch. Of course, there's also a huge treasure chest of prefab solutions online. You can go and use anything that's there already, because we have those on long history with passwords.

The same for other types of multi-factor. If you think about self-contained multi-factor, like TOTP. TOTP is like what Google Authenticator does, for example. The standard is TOTP. You can download a TOTP library. You can implement that rather simply and easily.

SMS is a little harder because you always have to integrate with some telecommunication infrastructure. There are lots of companies that will make that easier for you if you want to go and do that. Of course, they found a flash for making it easy, but fine. Another drawback of the telecommunication side of things is it's costly. It costs money to send an SMS. If you implement Google Authenticator TOTP, for example, you do it essentially for free.

Passkeys are the same way. Passkey, there's no cost involved from an institutional side of implementing passkey. On the user side, of course implementing it, like I said earlier, it involves asymmetric cryptography. That's a little bit more tricky than just your normal password hashing. It's a little bit closer to how TOTPs work, where you need to do a little bit of mathematical gymnastics to ensure that things pair up. But again, the big benefit is there are lots and lots of resources available right now, both in the open source space as well as in the commercial space.

If you are an organization, spanning the gamut, if you have a small website and you want to implement passkey support, you'll probably find something in the open source space or maybe in your favorite CMS already that does network. Or you're a larger enterprise customer and you want something that comes with all the bells and whistles, comes with a service-level agreement and everything else, you can probably find that now too.

A good resource for this would be FIDO alliance's website, so fidoalliance.org. If you go look at all the certified solutions, there are many. I think there's a whole number. I don't want to mistake that, but there's a whole bunch of different pages that you can scroll through to get to all the solutions that's at least at some level of FIDO Alliance eyes on it that's certainly quite for use. I would say if you want to do it yourself, you're probably going to have to figure out a couple of things and be pretty comfortable with cryptography and then all these things. It's possible. You have to work through the spec, but mostly you can download and get a library. Even in the open source space, that will do what you need.

Got you. Apple has adopted into their platforms the support for passkeys. Google has adopted it, Microsoft. OK, you've got most phones and most laptop, desktop operating systems. Those will handle it, but what about the adoption at the institutional level outside?Are you seeing a quick adoption? I'm trying to think through my mind of like, how many services I've seen who say, “Hey, we now support passkeys.”

Yeah, that's a great question. Actually, I just came back, maybe three weeks ago, from FIDO Alliance. This is currently called the home of pilgrimage down to San Diego, where we bring all of these companies that are interested in doing passkeys or the more interesting pieces as folks who've done it before, and we'll come with case studies and talk about what they did for their businesses.

There is quite a lot of organizations that either has plans in the pipeline for doing passkeys. In fact, I'm yet to see any large, institutional online service who is saying, “No, that's why we're not interested in doing this at all.” I think everyone is interested at some level. I think Amazon is probably the one I'll immediately just go out and mention. I even gave them statistics. I don't want to misquote them again, but I think they said something like 170 million customers or online accounts now has passkeys enabled for Amazon.

On the Google side, of course, we've got, I think, over 800 million right now that's been enabled. We're pretty happy with how things have been going there. Many other social media services have gone the same ways. There's obviously conversations going on. I think TikTok is another big one that did a bunch of work on the passkey side.

We've seen a lot of work happening in the tech space, social media, and others. What I'm looking for next, if you go back to the way that Jeffrey Moore thinks about product adoption, your real early adopters. Pretty much it doesn't matter, like innovator. We'll just go and we'll implement. It doesn't matter if this stuff is super rough edges.

You get into your early majority, and I think that's where we are right now. We're starting to see large-scale adoption of passkeys, but under very specific types of conditions, what we need next is our late majority, which is going to be more of your financial services, your government services. If you think about it, the services that have adopted passkey so far is the type of service who ask you for your password on a machine exactly one time in your life.

You don't ask Google on a machine; you type your password one time and you're signing in. We're not signing you out. Amazon is the same way. Many of these services work the same way. If we want to start to get passkeys into users' daily lives, we have to start to replace the daily driver authentication, the places where I type my password five times a day like logging into my bank. That is probably logging into something like government services, healthcare. Those are the types of places where I think users, if we're able to start hitting those, I think that will start changing passkeys from, “Oh yeah, so there's a new thing that I've seen in certain cases,” to, “Oh yeah, that's just how I sign into things now.”

I'm personally very focused in the FIDO Alliance as well in figuring out what are the things holding us back in those spaces? Most of the time, they're regulated, more cautious environment. Things just tend to move a little bit slower.

NIST, the National Institute of Science and Technology in the US, just updated their guidance on authentication. This is mainly aimed at government services, but a lot of consumer services also take guidance from this, where they've come out and say, “Passkeys actually are rated at level AAL2.” AAL2 is Authenticator Assurance Level 2, which typically means password plus multi-factor. If you're a service that does password and multi-factor like SMS, Google Authenticator, or some of those things today, you should be able to drop in a passkey today and still meet the guidance of NIST and AAL2.

There are some caveats and things there, but I think in general, that's the type of thing that we've been waiting for. We want to be able to point to external organizations saying, “Oh yeah, we looked at passkeys. We think they meet the criteria that you think you should meet, that your regulator or your internal auditor say you should meet. You're now unburdened. You can go and implement it.”

I will say we're starting to see a move in these slower industries happen as well. That is something that we're here to support. We'd love to see how we move those types of services to adopt passkeys as well. I think over the next nine months to a year, I think we're going to start seeing those services drop month over month as they're getting more comfortable with the technology. In most of these cases, it just takes them a long time to get stuff out the door. It might be something they started with maybe beginning of the year or last year. It'll probably take well into 2025 until some of these integrations are truly ready.

Got you. What follows passkeys? Are you guys working on the next iteration?

It's a great question. Knock on wood here. I think we've solved sign-in. I think we have a solution that hopefully will stand the test of time and on the authentication side, we'll be able to say, “All right, we think we've solved that problem.” Let me talk about that a little bit and then go off on a slight tangent.

(1) Passkeys really only give you the security benefits if you can stop supporting the old stuff. At this point, passkeys are still being presented for Google accounts and many other services as an alternative, but you can always fall back to your password if you feel uncomfortable with your passkey. Maybe you're on a new machine, you don't have your passkey, maybe you can't figure out how it works, I don't know. You can always fall back to your password; that's still an option.

Over time, we have to start thinking as an industry, “How do we start moving away from the old technology?” We can really only do that once users are comfortable enough with passkeys as the way that they authenticate. A bit of a challenge for us. I think that's the thing that over the next two, three years, we're going to start spending a lot more time on as an industry—guidance around completely turning down the password flows, or at least putting them behind more friction so that passkeys become the thing that you use. Again, if your password is still there, that's just what the attacker will trick you into using when they want to phish you. Get away from that. That's the most important.

Yeah. Passkeys are temporarily unavailable. Please enter your password without the PIN code.

Absolutely. (2) As we're solving or working on the authentication side, we're now starting to see attacks shift a little bit parallel-wise to what we call session hijacking. If you think about how the web works, running the web is stateless in a way, where every time that your browser makes a request to a service, it's like ground up there. It starts afresh. It tells the service, “Hey, here I am.”

Logging in basically means that there's a cookie, a piece of data that gets saved on your local machine. With all of the web requests, the cookie is attached. That's what gives you the logging status. If someone could steal your cookie, that gives you your logging status on your machine. They're now logged in just as you are. Once you authenticate it, when a cookie gets placed on the machine, that cookie should be kept safe. It should be protected.

We've started to see more malware focus on stealing off the cookie now, since the authentication side is now sufficiently secured. There's new technology that we're working on together with industry again. The particular piece of technology is called DBSC, Device-Based Session Credentials I think is what it stands for, which is a new standard, which is parallel to FIDO and to passkeys, which focuses more on how we protect the session credentials of these cookies in a better way now that devices have things like TPMs and hardware-based security modules, where we can go store some of these cookies and lock them away in a more secure, protected environment.

It's not really, “Hey, we need to do passkeys 2.0.” No, I think we're good there. We need to look at what are the alternative paths that bad actors can use to get into the system, and we have to start locking those down as well.

Yeah, it makes me think of there were a couple of, at least to me, high-profile stories, where YouTube accounts were taken over or hijacked. It was done. The people that were running the channels were discussing, like, “We reset our passwords, yet five minutes later, these people were back in our accounts.” Ultimately, it was determined that there was malware loaded on one person's machine. It was hijacking the session.

Exactly. I think I know exactly what you're talking about. I've seen that same episode too. Those are the things that we need to start focusing on because it's going to start happening more and more. As we're locking down the front door, bad actors will find a way to get in. They're going off during the next easiest thing, which at this point looks to be session hunting.

It's not like this is, “Oh, my goodness, the sky is falling.” This is traditional history, not this methodology, but hijackers, bad actors, threat actors, or whatever you want to call them will always choose the path of least resistance. “If the lock of the front door is too difficult to get through, then I'll just break a window. If the windows get too difficult, then I don't have to unlock the front door; I'll just knock the front door down.” There's always other opportunities. I guess it's good that at least that transition time is good for consumers in the sense that if one door is really secure and they haven't figured out what the next hole is, consumers are a little bit more secure in that period of time.

Absolutely.

If people want to learn more about passkeys just on a general basis, is there any good resources for that?

I think if you're just interested in the technology and you want to experience it for yourself, Google's got a great resource, g.co/passkeys. That's a good introduction or a good primer on passkeys. It also gives you a link to how to enable it for your Google account. Although nowadays, it's pretty hard not to enable it for your Google account. We've moved to a model where if you sign in with a password on a device that supports passkeys, technically, we will tell you about it and we'll try to get you to upgrade.

Again, you can go to g.co/passkeys and you can learn more about passkeys. Also, get into the backend of your account management page where you can see all the passkeys you already have, when last you use them. It's just a good resource in general. If you're interested from a developer side of things, fidoalliance.org is a great resource. Another great resource from a developer perspective is passkeys.dev. Great resource around the developer side of things, open source libraries, everything linked there.

One last thing I'll mention, fidoalliance.org, from that website, you can get to a resource called Passkey Central. That is something we just launched a couple of weeks ago down in San Diego when we went to the FIDO yearly Authenticate Conference that I was attending. Passkey Central is a business view more on what are passkeys? What are the benefits to your organization? How do things hang together?

From a technical developer perspective, I think passkeys.dev is a great companion resource that folks should look at. But if you want to make the case to your executives for why passkeys is a thing that you should consider, Passkey Central, I think, is a really good resource, all linked from fidoalliance.org.

Awesome. If people want to get a hold of you, Christiaan, what's an appropriate way for them to get a hold of you where they're not going to try to phish you?

My DMs are open on X, I guess now we should say, @christiaanbrand. If you go on X and you find me, feel free to send me a DM if you want to, just tag me in a post, or make a public post. I monitor those pretty frequently. I would say that's probably the easiest way to get my attention.

Awesome, Christiaan. Thank you so much for coming on the podcast today.

No worries. Thank you, Chris.