The Future of Passwords

Hi everyone and welcome to Cloudflare Research's discussion on Authentication Protocols today. Thank you so much for being here. My name is Wesley and I am the PM for the research team. I've been at Cloudflare now for almost nine months and I cover a wide surface area of products, including distributed web, post-quantum cryptography, next generation Internet protocols. And I am truly honored today to be with here with my fellow colleagues, former and current, to talk about some of the things that we're working here on at Cloudflare Research regarding authentication. Before we jump in, I'd like to go around the room and have everyone introduce themselves, starting off with Marwan, if you'd please. Thanks Wesley. I'm Marwan Fayed. I'm reasonably new as well as Cloudflare, coming up on a year. I'm a former professor and in that former life, co-founded an ISP for rural broadband and community networks. My own specialization is computer networking. And at Cloudflare, I'm one of the leads. We work on a number of things at Cloudflare Research. I'm sure we'll get to talk about those a little bit. But I will say this, having jumped from academia to industry, not planned, a brilliant environment. Anybody's thinking about it. Nice. Thanks Marwan. Chris, how about you next? Yeah, thanks Wesley. My name's Chris. I'm a research lead here on the Cloudflare team. I work on a variety of things, mostly on the intersection of networking, security, privacy and by cryptography. So the stuff we're going to talk about today kind of touches on all of these in one way or the other. And I'm looking forward to getting into it. Thanks Chris. And truly the star of today's show, a former Cloudflare intern, the author of our opaque blog post this week and the person who's going to tell us all about authentication protocols and where they're headed. Tatiana, if you wouldn't mind introducing yourself. Yeah, thanks Wesley. So I'm Tatiana Bradley. I was an intern at Cloudflare this past summer. I'm just finishing up a PhD in cryptography at University of California in Irvine. And I'm also a software engineer at Google. I'm really excited to be here today. Awesome. Thanks Tatiana. Before we go too far down the rabbit hole of pigs, cryptography and all sorts of fun, crazy math that makes my eyes bleed. Marwan, I would love to have you give us an introduction to Cloudflare research as a whole for those of us on the segment today that may be unfamiliar with Cloudflare research. Sure, thanks. So Cloudflare research as an entity, as a team within the company is actually fairly new. Many people know the research endeavor by the work that it's done previously on TLS, for example, TLS 1.3. We are engaged a great deal with the standards bodies, particularly the IETF, to advance, refine, and author new Internet standards. We're a growing team having focused on applied crypto, which is still the main focus, cryptography. We're branching out into the networking space, a little bit of systems. And crucially, the things that we do are important for the Internet. So we take to heart this notion of good for the Internet type of theme. Of course, with the added value that it's also good for Cloudflare and oftentimes driven by some of the problems that we see. Awesome. And I think what's great, you mentioned it specifically that Cloudflare is branching out from just Cloudflare research, I should say, is branching out from being purely a cryptography team into other areas of research. When we talk about authentication, a lot of people think about passwords. Can you tell us a little bit about why passwords might be problematic? I mean, I have a password, you have a password, I have a great password manager in one pass. Why should we even be thinking about the sort of like core Internet primitive? So this is a fabulous question. And passwords are a problem for the reasons that people are familiar with. They're hard to remember, they're getting increasingly complex, now we need tools or software to manage them. The more fundamental issue, however, is even if you set all of those things aside, even if you could imagine the notion of a perfect password, the truth is, as soon as the password leaves your brain, it becomes insecure, there's some risk to using it. Of course, you need to type it at your keyboard in order to share the password with other devices. But this is the really interesting thing now, even if you could secure your own device, and we secure the transmission channel over TLS, for example, I'm sure Tatiana and Chris are going to talk about this a little bit. When it gets to the machine, even if the machine does everything perfectly, the password itself still has to be processed. So there's some amount of time where the password is in the clear, and visible to outside entities, if they happen to get access to the machine. So and this is a fundamental problem with passwords, we'd love to get rid of them in their entirety. Nice. Thank you so much. And to talk about how we might think about getting rid of passwords in their entirety, or at least prevent passwords from going in the clear. We're talking about Opaque today, which is a newly proposed protocol for how to do exactly that. And Tatiana, you spent almost your entire summer with us here at Cloudflare working on Opaque, correct? Correct. Yes. Nice. So why don't you tell us a little bit about what pakes are at a high level? Yeah. So basically, what we're thinking about here is that whenever we want to communicate over, for example, the web, we want it to be encrypted. And in order to get a secret key to encrypt our communication, we need to have some kind of basis and trust. And the way that that's done in TLS, for example, is with public keys. But PAKE is a kind of another way to establish that trust. And the way that works is, say, I'm trying to set up a key with Chris. Chris has a password, I have the same password, and we're going to run a PAKE protocol and get a secret symmetric key that is the same if our passwords match and different if our passwords don't match. So instead of bootstrapping the trust from a public key, we're going to bootstrap trust from a password. Nice. Nice. I mean, this bootstrapping of passwords, I can imagine that PAKES come in a lot of different formats and flavors. And so what flavors of PAKES exist and why are they useful beyond just building this trust mechanism? Yeah. So the type that I just described is called a symmetric PAKE. And that's the case where I have a password, Chris has a password, and it's the same password. But what's really more useful in the web case is what's called asymmetric PAKE. And the way that works is, say, Chris is a website and I'm a user. I have a password. I remember it in my brain, right? But Chris doesn't want to have to... Chris has to store some representation of my password, but he doesn't want to have to store my actual password. And why not? Because password databases are notoriously stolen and all over the Internet. It's very bad. So basically, instead of storing the passwords in the clear, Chris is going to store what's called a salted hash of my password. And what that is, it's a randomized function of my password, which makes it much harder for attackers to learn my password if they stole the database. And so what does that mean for asymmetric PAKE? That means that... Sorry. That means that... You're talking about what that means for asymmetric PAKES. Right. Right. So that means that on my side, I have a password and Chris has a salted hash of my password. And an asymmetric PAKE is going to let Chris input that salted hash instead of the password. And I'm going to input my password and we're going to get the same output, which is a shared symmetric key. So basically, instead of bootstrapping the trust of having the same password, we're now going to bootstrap the trust of Chris having a derivative of my password and I have my password. So really, asymmetric PAKES are where it's at, and that's what OPAKE is. Interesting. Interesting. So I love this idea. So just to ladder it up to a really high level, this is a mechanism in which the server itself never actually has your full password in the clear, right? Right. That's so interesting. And I can imagine this would be useful for any number of scenarios. Chris, Marwan, Tatiana, talk to me a little bit about why haven't we seen this adoption in the larger web context yet? What makes this difficult? Yeah, I can take that. Sorry, Tatiana. I was just going to say maybe Chris could speak to that. Yeah. Yeah, sure. Yeah, so PAKES, as Tatiana said, PAKES have been around for a very long time, especially of the symmetric and the asymmetric case. I think we know how to build the cryptography. We know how to build the software, but primarily what has been stopping us from getting this into browsers is what the user experience is, especially as it relates to phishing, which is this problem that truly passwordless technologies such as WebAuthn are trying to deal with by just removing passwords from the equation altogether, not just blinding one side from the knowledge of the password at all. So there's not been a good proposal to bake in sort of a good user interface for interacting with a PAKE in a browser that's separate from JavaScript or something that's just running as part of an app that could be potentially a phishing site, could not be. And absent that, it's really it's been a kind of a challenge to get a kind of buy in. And as time progressed and just things like WebAuthn sort of sprung up, interest is sort of like moved away. But there's still there's still an opportunity here. As Marvin pointed out, like, yes, passwords are a problem for a number of reasons, but passwords are so ubiquitous because they're so much easier than, for example, remembering a very long cryptographic secret and then trying to punch that in like bit by bit on your keyboard or whatever. Like we know how to use them to some extent. Users are trained to expect passwords in some variety for authentication purposes. So there's going to be a period of time before truly passwordless technology such as WebAuthn fully take over the world where passwords will exist and we'll have to deal with this problem where servers could potentially mishandle passwords and asymmetric PAKEs such as OPAKE, which is something we'll get to in just a second, are sort of our approach to dealing with that particular problem. And we're interested in exploring sort of these user interface challenges that have come up to try and figure out if there's some sort of compromise that could be made between fully fledged browser support versus something that's written in JavaScript and if there's an incremental path to get there. Again, I'll table the future stuff for a little bit later. Don't spoil the fun at the end. I want to get back to talking about that JavaScript library in a second. But before we do that, you know, I think you keyed that up so nicely because, you know, Tatiana, we were just talking through the difference between, you know, the types of PAKEs, asymmetric PAKEs, we got to OPAKE. You know, let's go back. What makes OPAKE a special type of PAKE, really? Yeah, so really the special thing about OPAKE is that most or almost like basically all PAKEs in the past that are asymmetric have this property of not being randomized. So on Chris's side, he's the service. He actually has a function of my password in the OPAKE case, but it's a deterministic function. It has no randomization. And in the real web setting, that's just not good enough because an attacker can guess, can basically make a list of a bunch of likely passwords, calculate the deterministic function on those, and then basically as soon as any passwords are stolen, be able to determine all the passwords. So we really need this randomization for each password. And OPAKE allows us to do that. Nice. Just to help provide some context, too, about that, because, you know, we make it sound super academic. You know, a hacker may be able to do this. They may be able to brute force it. You know, for Marwan or Chris, you know, what's the realistic expectation in terms of computing power, right? You know, it seems like this is actually something that could happen. You know, easy to spin up a digital ocean box today and get a pretty high-powered computing instance for not very much money, right? Oh, I'm not sure. With things like rate limiting at the application layer to help deal with sort of these brute force attacks, it may not be as immediate of a problem as we think. However, the ability for the attacker to prime and do a lot of the work offline a priori to this actual compromise taking place, as Tatiana points out, is the real problem here. What OPAKE does is it shifts it so that that work cannot be done until, like, the breach happens, at which point, like, the attacker has to do a bunch of work, potentially rate limited by the application, potentially, you know, whatever other access controls or mitigations are in place. And there's a window between, like, the breach and allowing users to change their passwords. So, like, the risk is much less from, in OPAKE's case, because you can shift sort of where the work is required to happen. But just to be clear, like, to be fair, we shouldn't really be comparing against asymmetric PAKEs that already exist. We should be comparing against the standard practice, which is to have those randomized hashes, right? Right. So I want to give you an example from my former life, Wesley. Actually, in the year before I joined Cloudflare, one of the assignments that I gave to a systems programming course was, here's a password database. Here are the functions that are used to generate the assaulted hashes. Go out and break them. What are people's passwords? And you'd be surprised how quickly you can break some of these things in fairly short order with, you know, a little more than a home PC, if you target your efforts. So it's the sort of thing that it's safe to assume even the best handled passwords. So mishandling suggests that there's something irresponsible. And I think it's important to point out that even the responsible parties, things can go wrong. Things can happen. And so we tend to operate under the assumption that it is only a matter of time before passwords get out there. And then how do we respond to it? And this is the base case that Tatiana is talking about. Informing people that passwords have been stolen is a challenge in and of itself. So it's a less than ideal situation out there where passwords are concerned all around. That makes total sense. I think this is such an interesting discussion, too, because it brings in the notion of how do we think about the time periods between, you know, someone discovers a vulnerability, there's a breach, then users have the ability to change their passwords. It really does sound like adding Opaque into the mixture here helps us ensure that users have the longest possible time to be able to update their passwords, reducing the overall size of the breach itself. So ideally in a perfect world using Opaque, we don't have a breach in the first place because the server never has the password. What I want to go through is talk to the different types of Opaque, too, because, you know, from my uneducated point of view on this, it sounds like there are different types baked in here, particularly, you know, in AKE versus EA, for instance. Yeah. So the way that Opaque works, essentially, you can think of it like, so I have a password, right? And the service has this salt, this random piece of information, right? And you can think of Opaque as creating this locked box, this locked box that is locked by my password, and the server also locks the box using their secret salt. And when I first register my password with the service, I'm going to send them my special locked box that's locked with my password. And whenever I'm going to log in with my password, the server and I do this cryptographic exchange so that I can unlock the box. So I unlock the box and I get this secret information from inside the box. And then the server and I, after I've unlocked the box, the server and I do another operation called a key exchange and actually generate a secret session key that we can use to encrypt data. But in the case of TLS, for example, we actually already have a secret key. So if I've already established a secure connection with the server, then I don't need to do that key exchange. So the variant that we actually implemented is called Opaque with exported authenticators. And what that does is we just take the box. It's a really cool name, by the way, Tatiana, I have to say. Oh, yeah. We just take the box unlocking protocol, which is really called an OPRF, an oblivious pseudorandom function, to sound smart. We just take the box unlocking protocol and then we don't actually need to do the key exchange because we've already done a key exchange. We really just prove – I just have to prove that I actually unlocked the box and I do that using some cryptographic magic. But it's nice because we don't have to do that second part. So that's the difference. It's basically chopped opaque. It's shortened opaque because we don't need to do the second part. And that has some real performance benefits, I'm imagining, too, right? Oh, yeah, definitely. Yeah. Yeah, because, you know, when we think – oh, Chris, please. I just wanted to highlight something that was perhaps a bit subtle in what Tatiana said, and that was that the authenticated key exchange protocol that takes place or the authentication step that happens within exported authenticators uses well-known public key-based mechanisms for authenticating both ends. And we've known how to do this for a very long time, like using public key cryptography and digital signatures to authenticate parties in key exchange protocols or in other protocols is something that's been along for a while. And sort of the magic of opaque is that it allows us to go from a password to this sort of more, you know, well -established authentication mechanism by, like, putting these public keys and these private keys in this lockbox, as Tatiana says. So that's really kind of where the magic comes in. It glues, like, two things that we know how to do very well together to build, like, a strong asymmetric opaque protocol. Yeah, great point. Great point. I think it's such a good point to call out, as Tatiana was saying. So obviously we built something. What did we build? So who we built was opaque with exported authenticators. And in order to create opaque, you need buy-in from both sides. And that's one of the things that Chris was mentioning before, I think, in saying why it's a little bit difficult to get buy -in for PIX. And it's because both the browser or the client side and the server side both have to do things a little differently. So we implemented both the client side and the server side of opaque with exported authenticators. And one of the challenges there was that because we don't have the browser support that we need in order to implement the client side in the real, perfect, secure way, so we had to do kind of a hacky workaround for that. So that's kind of a challenge for adoption, for real-life adoption. But basically the takeaway is that we were able to show in a kind of proof-of-concept way that you can integrate opaque and TLS in this way that I was describing, where you grab some data from TLS, run just the box opening protocol for opaque, and then use what you decrypted from the box to basically prove your identity between both parties. Wesley, it's also worth pointing out that this demo is live and running at Cloudflare's Edge today. It is. You stole my thunder, Marwan. I was just about to plug that. Tatiana, if people want to see this in real life, right, and to really understand the back and forth between the client and the server, we have a running demo. I would love for you to shout out the link for it so we can go send people to it. Okay, so this relies on it being the same link that it was when I created it, which I'm not sure if it is. Can I get a verification? No, we changed it, Chris. What is it? It's opaque.research .Cloudflare.com. All right. Perfect. Yeah, so opaque.research.Cloudflare.com, and you can actually go there and play with the opaque demo, see the various interactions between the server and the client side to really understand the types of exchanges that are happening back and forth here. It's a really nice way to understand the protocol at the sort of nuanced level and the interactions that are happening. I want to also highlight one more thing. One more thing. So Tatiana mentioned that we had to work around the absence of certain APIs on the client side in order to implement this thing because there's not support for export authenticators, which is what this particular variant is built on in the browsers that we were using. However, even with this absence, we've still built an authentication mechanism based on passwords that works in such a way that the server never sees the clear text password, which is still strictly an improvement over password, over TLS. It doesn't have the strong binding to the TLS connection as the full secure thing, as she says, does. But this is sort of the incremental trajectory that I was alluding to earlier, where we start just kind of running opaque strictly at the application layer, so to speak. And then we ratchet things down and we tie it closer to the TLS layer if needed. Or if not. If clients and browsers don't think that the binding is needed, maybe it's not needed. Maybe you could just run opaque without the TLS layer binding. And there's starting code to do this. Right. Part of the thing that goes along with the demo is an open source implementation of sort of the core opaque library itself, as well as the wrapping logic that's needed to run it with exported authenticators. And we're working on building out TypeScript client and server implementation as well, so you could potentially experiment with it more natively in the browser. So coming soon. I think that's entirely where I want to start taking this conversation in the last five minutes is let's talk about what's coming down the pipe. I mean, from the Cloudflare research side, I think, correct me if I'm wrong, we're going to be publishing open source libraries for people to also play with opaque, correct? Yes, including the ones we already have published. Exactly. So because opaque is not just cutting edge, it's bleeding edge in terms of protocols. Right, Tatiana? Yes, bleeding edge. Yeah. It's very much one of the next incarnations. And we've talked about it a couple different times. We've mentioned WebAuthn. I'd love to hear from the panel a little bit about their thoughts about how opaque and WebAuthn live in the same world together. Is this a zero-sum game where one's going to beat each other out? Is this a world where we still need one and the other? As we think about authentication to the future, where are these protocols going to start taking us? Yeah. So WebAuthn, for those who don't know, I should have explained it when I first introduced it, or when Tatiana first introduced it, forget who. It is a very new-ish web authentication standard based entirely upon public-key cryptography, this well-known thing that I was talking about earlier. And it uses the hardware tokens, like the UV keys that you may have running with you right now, or it plugs into biometric authentication systems on devices you may have, or it's just like these tokens that support WebAuthn are kind of baked into the hardware, like in Google's Pixelbooks, I think, support it. And this is great for these new devices and these new client platforms and user agents that have support for this stuff natively. And the more we can sort of push WebAuthn out there and evangelize for it and increase its adoption, the better. Because, again, I think removing passwords altogether from the equation is the right move. However, like I was saying earlier also, there's going to be some time and some clients for which that's simply not possible. People won't update to the latest device. People won't be able to run or access these keys. Maybe there's even accessibility problems with using the existing hardware tokens that back WebAuthn. So for this reason, passwords will be around for a little while longer. And we expect or we would like to see if there's a way that OPIC can sort of help make password-based WebAuthn mechanisms as most secure as they can possibly be, up to just removing them entirely. And we think that's what OPIC brings to the table. So in some way, they're sort of complementary, right? Like you could run just WebAuthn. You could run OPIC. You could run them together. And likely what would happen is if you're a web application or an origin happen to or trying to choose between one or the other, you might just support both. Especially if we find a way to run OPIC natively without browser upgrade support, like just using JavaScript running on the client, sort of what Tatiana's done for her demo. And, I mean, it's sort of a strict improvement over where we are today. But exactly where we go in the future, especially as WebAuthn evolves, as OPIC evolves, is a topic we're actively exploring. And seeing how we can improve passwords on the Internet is something we're trying to address. So I'm actually, Wesley, I want Chris's future. I happen to be more pessimistic, which I'm surprised at myself for saying, because I believe in a WebAuthn future. But there are some problems that WebAuthn alone is going to have a hard time solving, which is the authentication mechanism attached to WebAuthn is attached to the device. So if it's a fingerprint sensor on a mobile phone or a YubiKey, those are fine on that device. But when you move to another device, that usability exercise, how does a user then use the authentication mechanism from one device on another? These are problems that have yet to be solved in their entirety. And then there's just people are slow to shift. I think there's this other one. Or if you lose your device, what do you do? So I'm a little bit more pessimistic in that I desperately want that WebAuthn future, that passwordless future. I just I suspect it's going to be a very, very long time on the order of years, if not more, before we make any real strong headway in that direction. Nice. There's been research on usability concerns in terms of password managers and why they haven't been adopted. You might argue that a password manager is the perfect solution to insecure passwords, like I love Cloudflare, which I'm not saying that is or is not my password. Because they generate very strong cryptographically unpredictable passwords that presumably you wouldn't be able to crack given enough compute time or power in our lifetime. But not everyone uses a password manager. So, yeah, to Marvin's point, there are barriers to adoption to better things. So it seems prudent to see what can be done in the interim while we're trying to go up this adoption curve. Awesome. Well, I want to take the last 40 seconds and thank you all for being here today and sharing in depth about opaque and authentication protocols. And Tatiana, if people want to learn more about this, learn more about your work, your PhD thesis, you know, where can they go to find out more? Well, they can definitely read the blog post recently published. And if you want to I mean, if you want to learn about me, just like Google my name, I guess. I don't I don't I don't have a website to plug, but just Google my name, Tatiana Bradley. You can email me if you like Tatiana E. Bradley at Gmail. Perfect. And with that, thank you so much, Marwan. Thank you so much, Chris. Thank you so much, Tatiana. This has been a segment from Cloudflare and Cloudflare Research talking about authentication protocols on the next generation of the Internet. Have a good day.