🎂 Why security keys are the safest way to secure the web - Fireside Chat

Okay, welcome to Cloudflare TV, a special edition all about the FIDO Alliance and hardware keys and all things multi-factor authentication. I am John Graham-Cumming, Cloudflare's CTO, and I am here with a special guest, Andrew Shikiar, who is the CMO of the FIDO Alliance and Executive Director. Andrew, welcome. John, thanks for having me. Thank you for coming on CFTV and having these conversations. We like to get kind of nerdy on these things and talk about some of this stuff. And I think hardware keys are in the news quite a lot because of how strong they are as a protection. But I bet most people haven't heard of FIDO Alliance, or if they have, they're not quite sure what it does. So why don't we start you telling us a little bit about what you do and what FIDO Alliance does. Yeah, absolutely. So FIDO Alliance is an industry body of around over 250 companies worldwide who are working together to create open standards for simpler, stronger user authentication. I see we're on Cloudflare's Birthday Week. We're coming up on our 10th anniversary, actually. So we've been at this for 10 years and have put out several protocols to basically do user-friendly asymmetric public key cryptography. These standards are supported in a variety of products, B2B products and B2C products that allow for unflinchable multi-factor authentication. And now I use, right here I've got a couple of keys I use all the time. This is a UV key with USB-C and NFC, which I actually use with my phone. And I've also got another one here. This is my personal one. This is a little USB-C one. And I've got another one in my laptop, which is one of the little tiny ones, which is permanently attached to my laptop. And Cloudflare uses these extensively. So when you say asymmetric encryption, what's going on with this device and asymmetric encryption when I press the button here? Yeah. So let's back up a little bit about what FIDO's standards are doing. And so they all support asymmetric public key cryptography. What I'm saying there is basically, we're trying to shift the way that people authenticate from being dependent on essentially stored passwords to a model that's a little bit more decentralized in nature and allows users to authenticate locally on their device. And when you think about it, if this is a typical model, you have a person and the password over here, there's this big gap in between where a remote hacker can come in and phish someone. They pretend to be a legitimate site or pretend to be a legitimate user if they have the password. And that's the problem, is this kind of open communication between user and server. With public key cryptography, what you're doing instead is actually creating a unique key pair for every service that the user is enrolled with. So in this sense, once I enroll FIDO authentication, I'm putting a public key on the server. And then there's a private key stored locally on that device. Now, unlike a password, if someone has my public key, there's no value to it. You can have my public key and you can't do anything with it. Whereas if I had your password, I could probably, since most people have lazy password habits, I could probably log into other sites with that password and another credential. But again, going back to public key cryptography, the public key has no value. The private key is on the device. And the user must verify themselves to the device, to the private key, before the dialogue can happen between the key pair. Once I verify myself, then there is a encrypted communication between the private key and the public key, between the authenticator and the server, that allows the authentication ceremony to take place. Now, in the security key example, all I'm doing is actually proving possession and presence of that device, which is a very simple concept. I'm literally touching my security key, proving that I am in possession of that device. Other ways of doing verification include biometric. So I use, like you're showing the keys you have, I have a key in my key chain, which I use for my phone. I have a nano embedded in my laptop, but I also use Windows Hello. So Windows Hello is allowing me to use a local biometric or local pin to verify myself with the key embedded on my Windows PC. So all these things are local authentication taking place. And then once I do that local authentication, the key pair has a dialogue to allow me to sign into a website. What's not happening, what's not being transmitted is any sort of human-readable shared secret over the network. And again, that's the threat factor. One of the main threat factors is that communication over the network that can be spoofed or hacked otherwise. And again, with security keys and FIDO authenticators, that's simply not possible. So I think there's an interesting point, which I think a lot of people miss, which is that when you talk about phishing, for example, so I think phishing is one of the big threats that these help defend against, which is that people will say, well, I use Google Authenticator or some other TOTP device and I have to put in a one-time code that can't be phished. And of course, that is actually completely wrong. Yeah. I mean, look, so any form of 2FA is better than a password alone, right? Even SMS OTP. And that's really the main threat, for the mass market is SMS OTP as a perceived strength of 2FA. And it is, again, it's better than a password alone, but to going back to this model where you have this server and the person, there's this gap in between where an attacker can sit. And so all they're going to do in that case is relay your SMS code or OTP code or TOTP code, right? They get in the middle. And then again, you think you're logging onto a legit site, you enter your password like you always do, you get a code back on the backend, they're relaying that onto the real server. The real server sends you the request for your OTP, you enter it and they then enter it into the real site and they've taken over your account. Yeah. And this is not at all theoretical. People really do this. And in fact, so we had an attack against Cloudflare. We wrote it up on our blog a little while ago where somebody figured out a load of phone numbers for Cloudflare employees, texted them a thing saying, hey, you need to click on this link because some excuse about IT needing to do something. People clicked on that and it then asked for username and password and TOTP token. Now, Cloudflare doesn't use TOTP. This was actually done against 130 other companies that did the same attack. But had we done, if the person had typed in the TOTP token, which they got from an authenticator or fee or whatever, on the backend, it automated immediately doing the login on Cloudflare because they just passed because you got 30 seconds, so you can literally do it automatically. And that's how companies, even though they've gone the extra step of that second factor using TOTP, they get into trouble. And for us, the keys really, really helped us in conjunction with our product, Cloudflare Access, which allows us to enforce the keys on any application, even if itself doesn't support keys. Yeah, I think that's exactly it. And that's the strength of it. And so when you think about that attack, at the core, phishing is a very successful attack mechanism, as you suggest. A well -designed phishing attack has over a 50% success rate. So not just someone clicking, but someone actually getting phished. So you're talking about spear phishing or these corporate attacks where they have some inside access. Ultimately, what these attackers are doing is preying on the good nature of your IT admins. And your admins are getting these messages saying, hey, you got to click on this security alert, whatever it might be. And people are like, yeah, of course I want to do this. And I think they're doing the right thing. And so what they're doing is really taking advantage of our human nature and our passions. And I think we need to move from passionate human decision making to a more dispassionate algorithm making that login decision for us. No, that's absolutely the case. In any reasonably sized company, it's very easy for people to fall for these phishing things. We've seen ones that were very well targeted, very well sent to people, no errors, and then the pages looked exactly right, everything that's correct. And people will fall for that. And you really can't blame people for falling for something which has been designed to trick them. And people, as much as they want to be vigilant, you just need to put them in a position where, well, it doesn't matter whether they made the mistake or not because something helps them. And the best solution we have right now is these types of keys and other similar devices. Yeah, I totally agree. And I think that it's almost putting too much pressure on your employees to ask them to be like a shadow IT team, your infosecurity team, and learn how to spot phishing. Obviously, everyone should be aware and be able to make good decisions. But the bad guys are good. They're good at their jobs. They're professionals. And not only that, they have professional toolkits. I can go out and buy a phishing kit with full customer support for a couple hundred dollars a month. Fully supported professional software as a service for me to take over people's accounts. Exactly. To ask all your employees to fight against that, it's unfair. Yeah, I mean, and it's the level of sophistication that I know of an instance where the phishing attack got in successfully through someone on the security team. And if someone on the security team is falling for it in a company, then you really don't have a hope that the average employee is going to understand the entire landscape of the types of attacks. So back in 2018, we decided to give everybody in the company keys and enforce use of those keys for services. Initially, the services that Cloudflare runs internally are internal control panels and things, and then for everything else out there. And one thing that was interesting was there are lots of applications, lots of SaaS things that do not support hardware keys. And so what we did is we built into Cloudflare Access, which is part of our Zero Trust solution, the ability to enforce the key. And that way, when I access anything at Cloudflare, whether it's an internal application or a SaaS application we use, I have to have the key and I have to prove that it's me. We were talking earlier, it was before we started, about the fact that you think at some point there will be SLAs, so that companies will say to their service providers in the contract maybe, please tell me that you protect your infrastructure using keys, because that way I can be sure. Because of course, the issue is if a service provider gets hacked, then maybe your company's private information has got hacked in some way. Yeah, I think that's a direction I'd love to see a lot of companies go, companies that have a lot of buying power. As we offload more and more critical functions to cloud service providers, it doesn't mean you're offloading your security. In fact, you should have the same security practices that you wish to enforce inside your enterprise should be enforced by your cloud service providers. And so I think it's logical to ask them to enforce MFA and official MFA with FIDO security keys or FIDO authenticators. So I don't know if anyone's doing that right now, but it's certainly a direction we'd like to see companies moving in, because ultimately that will improve the security of the Internet on the whole. Yeah, I'm assuming at some point this ends up getting built into security standards, you know, the ISOs and the SOCs and all that kind of stuff. But this is just a requirement to do this because it is so much stronger. Yeah, if you look at the arc of FIDO and what we're trying to do with FIDO authentication, I think a pretty good analog is SSL. When SSL first came out, it was kind of supported in patchwork and different browsers, operating systems and sites. And now it's just there, right? And so we're seeing FIDO the same way. FIDO is now built into every major platform, every major device. So every device being unboxed right now, almost every device supports FIDO authentication built into it. So we do think it'll take the same kind of trajectory where it's just kind of built into everything we do. And so there'll be supported more standards will become kind of a default way of doing things. What we're seeing in the marketplace with these different types of attacks and the octopus and lapsus and all these things, you know, there are still vulnerabilities out there. And they're non -trivial, right? So any of these major cloud services being disrupted by a nefarious attack could have huge ramifications. And so it's critical that cloud services in particular move quickly to implement unfishable FIDO authentication. And let's just talk about all this acronym soup because there's a lot of terms here, right? So there's FIDO, FIDO2, U2F, WebAuthn. Take us through what we need to know about the different standards here because I worry that one day somebody is going to be not sure they've got the right key because it doesn't support the right standard. So if I want to do this, what should I be looking for? Okay. And any sort of FIDO authentication has, again, asymmetric public key cryptography underneath it. But our lineage, let's go through our lineage, right? I said we're coming up on our 10th birthday. When FIDO first came out, there were two initial use cases that we were looking at. The first one actually was a biometric reauthentication use case where a couple of companies went to PayPal way back in 2012, I guess, when the Galaxy S5 first came out, the first Galaxy device that supported a fingerprint scanner. A company called KnockKnock, another company went to PayPal and said, hey, look, we have a way for you to allow your users to sign in without a password. All you do, they sign in once and they use the biometric and then they can be signed in every time without using a password again and again. And to PayPal's credit, they said, yeah, this is interesting, but I want this to be a standard, not a bespoke thing. And so that was one of the first use cases for FIDO. And that standard was called UAF, to add another acronym and turn it into special. Universal Authentication Framework, a biometric kind of app-based sign-in, which is still thriving today and for hundreds of millions of users worldwide in native apps. At the same time, another use case was being developed by Yubico and Google, Lenovo, a couple of others, which was U2F, Universal Second Factor. And this was basically having a key as a second factory device where you securely can just touch the key on top of a password to log in. So this was kind of early 2FA approach. But again, the same underpinning of public key cryptography and privacy preserving technology. So those two things were both within FIDO Alliance, those were our first protocols we put out. At the same time, FIDO was starting to develop something we're calling our FIDO 2.0 web APIs. And this was going to be where FIDO starts hitting the platform and the web itself. FIDO made the decision, FIDO Alliance made the decision in 2015 to submit these to the W3C. W3C sets the standards for the web itself. So we submitted these to W3C and the web authentication working group within W3C was formed. So when you hear about WebAuthn, that's the protocol that this working group created. So naturally, from the way these things work, a lot of the same people inside of FIDO's, FIDO Alliance's technical working groups also sat in the WebAuthn working group. And so these things progressed in parallel. So WebAuthn is basically an API that any web developer can use to allow for passwordless authentications on a website as opposed to using a password. So WebAuthn is in on this track. And at the same time, we were evolving kind of the client side piece of it inside of FIDO Alliance called CTAP or Client-to -Authenticator Protocol. That's what E2F kind of merged into. So the E2F lineage kind of moved into CTAP and then you have WebAuthn up here. And these two things together are FIDO2. So when you hear about FIDO2, it means there's a WebAuthn call, WebAuthn API call. And then on the client side, there's a CTAP authenticator, Client -to-Authenticator Protocol Authenticator. Those two things are FIDO2. So FIDO2 is kind of the umbrella standard for WebAuthn plus CTAP. And then UAF continues to kind of persist in its own way for native-first applications. So I do know there's a lot of acronyms there. So you'll hear about FIDO2, U2F. Generally, if you have a security key in your hand, you're in good shape. FIDO2 brings the ability to do completely passwordless sign-ins as a primary factor, whereas U2F is truly only a second factor use case. Got it. And there's one other, throw in one other acronym to the mix, which is some of these keys are FIPS as well. Yes. So YubiKey, for example, supports FIPS, support PIVS. There's other protocols and standards out there that are adjacent to FIDO and added security measures that some companies may require that can also be available on some of these keys. Yes. We have to use these at work as well. All of mine have got FIPS written on the back of them as well. Interesting. Yeah. So one of the things that's interesting to me is that at the beginning when I was using these keys, because I've been using them for a long time now, I felt like I was really a pioneer, right? Nobody else seemed to know what they were, and now they are. And now they seem to be cropping up a lot of places. And the big experience for me was once NFC worked really well. So I have a company phone and I have to authenticate using this key right here. And I do that just by bringing this key next to my phone. And it really works seamlessly now. That was one of the messages, you know, one of the things for me is it's a lot smoother. And the other thing is, this is actually easier than authenticator. You know, I go find a six-digit number and remember it and change and type it in, all that kind of stuff. This is actually more secure and easier, which in security world actually is a little bit unusual because usually security things are a real pain. And I think the only difficulty is you have to remember to keep this thing with you. But I know how to look after my house keys. Now I know how to look after my Internet key. It doesn't seem like a huge burden. No, that's exactly it. And the best practice is to have multiple keys, like we just talked about. You've talked about three keys. I have three keys I use, plus the platform authenticator is built into my devices. So I think multiple keys is the way to go. It is easier to use. And actually one of the pain points, let's not forget that this is addressing is kind of the token key chain problem that a lot of network admins have. We used to have an individual RSA token for each service that you had to log into. With a security key, you can have multiple keys for multiple services. So multiple private keys for multiple services on a single device. So my single embedded key on my laptop, I use for dozens of sites as a primary or second factor. Yep. Yep. And also the other thing is if I get a new phone, this works with the new phone. I don't have to move my authenticator over and deal with all the seeding of that and all that kind of stuff. It's just very, very simple. And I can have multiple of these. So if I lose one, then, well, I lost one and I can get rid of that one and use another one. I've found it to be a very easy experience getting these things working with pretty much everything. Yeah. Yeah. No, it is. It's interesting because the market has evolved. So initially I'd see, we'd hand these out at events and stuff, people would be like, well, what can I store in here? I think they're like, you know, especially the USB format, they think it's like a USB storage file, but it's not. And so it is easy to use. Again, people should have more than one in case you do lose one. But once you get the practice down of using security keys, especially inside the enterprise, it's a very, very intuitive way to go. I agree. Let's just talk about something you've mentioned a few times, which is platform authenticators. So just dig into that. I think I know what you mean, but let the audience know. Yeah. So platform authenticator is basically where you have the functionality that we're talking about built into the device itself. And so this, you know, it's like, so on your desktop, for example, I'm on a Windows desktop, Windows Hello has a FIDO platform authenticator built into it. So I'm given the option of logging in with Windows Hello rather than using my security key. Or as one was one modality, actually Windows Hello, you can use a key, face, fingerprint, or pin. Let's say on my iPhone, it's manifested as face ID. It's kind of the biometric on top of it, but underneath there is a platform authenticator and where my private key can be stored. So what WebAuthn has enabled, I think it's been really powerful actually to allow for a lot of these platform authenticator use cases to come to the fore as well. And where that gets interesting is a little bit outside of the remit we're talking about, but you start talking about consumer use cases and taking passwords out of the hands of consumers and prosumers. So WebAuthn allows you to do that today. You know, many leading sites are doing that. You can go to eBay, for example, eBay. If you have an eBay account, you log in on any device, they'll ask you, hey, next time, do you want to use your biometric instead of your, instead of a password and presto, you know, you're no longer using a password. And where this is heading, actually, the direction this is heading is something we've been talking about more recently called passkey, which actually allows a private key to be securely synced across a device cloud, such that you don't actually have to enroll each device. So for consumer use cases in particular, I think that holds a lot of potential to immediately start taking passwords out of play for consumer applications. Enterprise, I think that there's certain things around key management and attestation where security keys will still remain a predominant approach for protecting enterprise employees. Yeah, I do get the sense looking at, you know, I'm a big, I'm a big Apple user. You know, Apple has talked about passkeys a lot, and it's like exactly that, right, which is they've got all the biometrics, be it Touch ID or Face ID, they can identify that it's me, and they can then unlock access to a private key to do this protocol. And that's pretty powerful, because then I don't have another device with me, I should just use the device I trust pretty much for everything else. That's a very, very sleek experience. Well, you know, one of the challenges, frankly, with FIDO has been usability challenge. And the conversations I've had over my several years being with FIDO Alliance have shifted from, you know, initial conversations around, like come entirely from a security posture. It's more and more from a usability posture. Right? So how are my, how are my customers going to be able to use this? How are my employees going to support this? How are they going to know what to do? And so usability is important, especially as you start looking at the consumer use case, where people are used to using passwords, they're accustomed to it, and they're having to opt in for this, right? Cloudflare, you're appropriately mandating security key usage. But consumers have choice, you know, so how do you get, you know, how do you address the usability issue? And we've looked at this very closely. And one thing we've done is actually, we've done two very extensive research studies, one for the platform authenticator use case, and one actually for security keys. And both of them give guidance on how to most effectively implement FIDO for both use case. Right? So looking at things like, you know, for the platform authenticator use case, it's like, how do you message this to consumers that what you're doing is secure? How do you tell them they're adding an option, they're not losing something? And what was fascinating for me in this research was that none of this was technical. And none of it was actually designed, like as far as like fancy graphics, it was so much about messaging, and education, and how you, you know, get people to gradually become comfortable with this concept and opt in to use FIDO authentication. For security keys, you know, one of the challenges we saw going into the study was how people manage their keys, because it's very inconsistent, you know, outside the enterprise, but for prosumers, how do you manage your keys? And the experience is so varied from site to site to site, we want to give some best practices. So we start seeing people move in the same direction, which will also help accelerate usage in a variety of centers. So both these are documents that we've put out to the public, they can download on the FIDO website. Yeah, very interesting. Very interesting. Because I guess, even me, super technical, I kind of trust the key more than I trust the platform, because I'm kind of like, I can unplug it. It's like, here it is. And I know where it is. And I keep it in my pocket or whatever. And then the platform stuff, I'm like, I get, I get the crypto, but I guess, you know, I'm a little bit worried about it. But I can also see the other members of my family for whom it would be a huge upgrade to use pass keys to what they're doing. Yeah, I think so. And the nice thing is, it really scales across each use case we're talking about, each persona we're talking about, right? So we can't ask everyone to go buy a $40 piece of hardware. Yeah, that's true. It's very expensive as well. That's why the enterprise certainly should do. I mean, $40 of a key is much less expensive than the cost of a data breach or anything else. Crazily cheap. Yeah, it's just fantastic. And you know, of course, if you're buying them in large quantities, they're less than that. But that's the nice thing here. That's the great thing about standards and having this body, FIDO Alliance, working together to address these use cases, because we have stakeholders who care about different things, right? We have stakeholders who only care about the enterprise. We have government stakeholders. I mean, a major thing happened this year in the US, when the Biden administration announced its Zero Trust strategy and cybersecurity initiative. And basically inside the federal government now, they're saying, as part of the Zero Trust architecture, that government agencies can use any unfishable authenticator in addition to PIV and CAC. So two acronyms for our discussion. PIV and CAC are, you know, smart card technologies that require advanced identity proofing. Super strong, super great. But when you talk about all of a sudden, you have remote employees and trying to prove people can be difficult. Now, all of a sudden, they can use FIDO security keys in addition to PIV and CAC. A hugely important announcement, which also then trickles down into regulated industry, trickles down to industry at large, where they're seeing people say, yes, this is another way of allowing for user friendly, you know, easy to deploy unfishable authentication. And so that's another use case. We have those use cases, consumer use cases, enterprise use cases, we're looking at IOT as well now. So like, all these things require unfishable authentication. And so our standards can underpin all these use cases. Good. Listen, before we wrap up, because we've only got a couple of minutes left, you mentioned something which I suspect a lot of the audience haven't thought about, which is attestation, especially in the enterprise. Just briefly explain what that means. Well, so I think with the key, you want to know the provenance of the key and the provenance of the user who has the key. So with the FIDO security key, if you use enterprise attestation, you can make sure that that person is on the device that was actually issued to them. So that individual key to that person, which gives a higher level of assurance when the login happens. Exactly. They want to know exactly who's keyed and where they got it from. Yeah. And that is important. It can be an important thing for enterprises to deploy. For consumers, that's rarely needed. That could be counterproductive. So I think it's really important as you understand attestation to think about the use case for it within your own organization. Well, listen, Andrew, thank you so much for spending time with me talking about all these technologies and solutions on Cloudflare TV. This is obviously, at least I think, and I know that you do think this is a very vital part of security for all of us enterprises and individuals. And we're all going to get used to having either keys on our key ring or something built into our devices. Super. Thank you so much, Sean. Cheers. Have a good rest of your day. You too. Q2's customers love our ability to innovate quickly and deliver what was traditionally very static old school banking applications into more modern technologies and integrations in the marketplace. Our customers are banks, credit unions and fintech clients. We really focus on providing end to end solutions for the account holders throughout the course of their financial lives. Our availability is super important to our customers here at Q2. Even one minute of downtime can have an economic impact. So we specifically chose Cloudflare for their Magic Transit solution because it offered a way for us to displace legacy vendors in the Layer 3 and Layer 4 space, but also extend Layer 7 services to some of our cloud native products and more traditional infrastructure. I think one of the things that separates Magic Transit from some of the legacy solutions that we had leveraged in the past is the ability to manage policy from a single place. What I love about Cloudflare for Q2 is it allows us to get 10 times the coverage as we previously could with legacy technologies. I think one of the many benefits of Cloudflare is just how quickly the solution allows us to scale and deliver solutions across multiple platforms. My favorite thing about Cloudflare is that they keep development solutions and products. They keep providing solutions. They keep investing in technology. They keep making the Internet safe. Security has always been looked at as a friction point, but I feel like with Cloudflare it doesn't need to be. You can deliver innovation quickly, but also have those innovative solutions be secure.