 So, welcome to the very first episode of our new workforce identity developer podcast, recorded in March of 2023. I'm Emily DeHumans, eDunham to computers, and today I'm joined by Mega Rastogi, an Octa Product Manager in Access Management. That's quite the job title, Mega. What does it mean? Yeah, thanks, Emily. So as a Product Manager in the Access Management team here, I work on understanding the customer needs around multi-factor authenticators, more specifically our workforce customers, their needs, and building out great user experiences for them. We want to make sure that they're able to set up their authenticators, use them for recovery, enrollment, authentication properly, and be able to be protected from all types of threats. So if you've heard about this podcast, you've almost certainly heard about Octa, and maybe even heard the company's top-level goal is about freeing anyone to safely use any technology. Workforce refers to a subset of that audience, a problem space that's characterized by this unique set of challenges and requirements. So, Mega, what do you mean when you talk about workforce identity? Sure, yes. So we talk about workforce and consumer. So focusing on workforce, when we say workforce, we're referring to the enterprise customer needs. So what that means is protecting their employees, business partners, and contractors. And we want to make sure that we have provided them with secure access to their resources within the organization. Yeah, so when we talk about workforce customers, we're talking about those particular challenges of identity within a business. So identity is part of any business's infrastructure. If the right people can't access the digital or physical assets that they need to complete their tasks successfully, that's terrible for the business. And similarly, if unauthorized people are able to use the business's virtual or physical resources, the potential problems are limited only by the attacker's imagination. So Mega, are there other considerations that are unique to workforce identity? Yeah, absolutely. In a workforce use case, you are, suppose you're an employee, you're hired by the organization. So they know a little bit about you, they have probably your email. And what they want to make sure is that they can protect you, your identity, as well as all the resources within the organization. So that's why security is super critical for workforce use cases. And which is why admins generally control the authentication preferences and access for their users. So they'll set up policies around who can access which application at what level, and that's all controlled within the organization compliance and regulatory requirements. Okay. What are some of those compliance requirements that people might have heard of? Yeah. So generally, there are different assurance levels that companies need to meet their compliance standards by, and actually NIST or National Institute of Standards and Technology, they have defined very well the authentication assurance levels and what they mean. And a lot of times when more sensitive apps require AAL2 or 3, that probably means they need things like phishing resistant authenticators. Yeah, I've heard that AAL1, that's just you have to have memorized a password, referred to as pre-breached authentication. So it seems though, like it wasn't that long ago when memorizing a long, secure passphrase, maybe sticking in your password manager was the state of the art in digital security. What changed? Yeah. So passwords, which are just secrets, they are, as you can imagine, very hard to memorize for a human brain, right? So either what you're going to do is create a very easy, secret password, perhaps like one, two, three, four, five, six, which is the most common password. Or what you're going to do is create a really complex one and you're going to forget it. You're going to write it down and it's going to get compromised. And you're probably going to reuse that same password for ease of use at multiple sites. So once it's compromised in one place, the attacker will have access to all your accounts. So it's easily, very easily compromisable. Yeah. And even if someone does use a password manager, there's various ways to intercept it. And then when you have their password, you are them. In the ops space coming from a DevOps background, we have had an alternative to passwords, which is public key authentication. I could generate a new key pair locally, then give someone my public key, and then they could use that public key and some math, of course, to test whether someone claiming to be me really had my private key. So this was more secure than passwords, but there's some major problems. Like if you lost your private keys, you were just locked out. And if someone got a hold of your private key and the passphrase to it, they could impersonate you just like they had your password. So pub key auth is actually still how you bootstrap your way into a new cloud instance on most cloud hosting providers. But it was never practical for most people to use in accessing most systems. Most people were stuck dealing with passwords. Right. And to address these problems of passwords, we developed actually multifactor authentication. That's why we have MFA. And what that means is actually, there are three types of factors. So something you know, knowledge factors like passwords, something you have possession factors like your smartphone, or something you are like your biometrics, your fingerprint. So multifactor authentication requires two, at least two of those factors. So something like a password plus a t o t p or a push would be a legacy multifactor authenticator. Yeah. And we call them legacy now because attackers figured out a way around the legacy MFA systems. If you have a user's password through any of the ways that you could get passwords when it was just password auth, all you needed to do was trick them into giving you that temporary one time pad or authenticator code. And now you can impersonate them. That's right. So we had first just secrets like passwords. So that was the worst of all, then we added legacy MFA. So that was a bit of friction for the attacker. They found something they, that's what we call phishing. They actually got very sophisticated with social engineering techniques. And also in the market now we have phishing kits that actually intercept OTPs. So phishing attacks are very easy to implement now. And actually the most concerning form of phishing is using real time phishing proxies or what we call adversary in the middle attacks or you may have heard of middle man in the middle attacks as well. So in these attacks, what's happening is the user is getting tricked into entering their credentials into an attacker control phishing site that acts as a reverse proxy. So the user thinks they're entering the credential on the right side, on the legit side, but they're actually on a phishing site. The phishing site takes their credentials. They might even send them that push notification. The user will go ahead and accept the push notification. And that in credential and acceptance is related to the actually the legit site. And what is happening here is the attacker will go and steal that session cookie and the credentials. So that session token and the credentials are stolen and return to the user's browser. Oh yeah, there's all kinds of ways that can go wrong. It's like that set of scams where you can tell that they had scams because they started adding never, ever give this code to anybody in those text messages from your bank when you're logging in and also making a malicious domain name look just like a legitimate domain name. It's easier than ever now that there's Unicode support because there's so many different Unicode characters that'll all look the same in most fonts to most people. So even if your user is doing their best trying to visually check that they're on the domain they think they are check. Oh yeah, there's a little green lock. There is a certificate that was issued to the domain that I'm on. They can still be fooled. So that brings us to the modern identity landscape and today's topic fishing resistant MFA. So to start with the hard question, why do we only call it fishing resistant and not fishing proof? Oh yeah, so fishing proof is kind of absolute as you can imagine. So resistant is sort of relative and there are always going to be things outside of the organization's controls. So for example, with fishing resistant authenticators we can control the attacks on the identity, but what do we do about the end point-based attacks? So if your device has a malware and your session has been hijacked in other ways, that's something beyond what an authenticator can solve for. But fear not, that's why in security we have the layers of defense. So their fishing resistant authenticators is one line of defense. Beyond that there are policies, there are workflows, there are monitoring tools, there are EDR tools, all of these build up to help protect you overall from fishing attacks. Yeah, absolutely. Like if you don't want to get hurt in a car crash, you have to not only maintain your vehicle but also wear your seat belt, just those layers. So this fishing resistance is going to make it impractical for attackers to execute the types of attacks that cause those problems with passwords and with legacy MFA. So WebAuthN is a standard that's developed by FIDO or the fast ID online alliance. So to use WebAuthN what you need to have is a hardware authenticator and a supported browser. So Mega, how does WebAuthN put those two things together? Yeah, absolutely. So FIDO to WebAuthN actually utilizes that public key cryptography to verify your identity. So users can authenticate using their biometrics factors such as your fingerprints so you can do a touch ID or facial recognition or by actually tapping a security key like a UB key. So what this does is this provides a more secure way to authenticate users because it requires that physical factor like your touch ID but and this cannot be easily replicated or guessed as well. So how all of this is actually working is there are two parts to any authenticator. One is the enrollment and one is the verification. So let's talk about enrollment. So when a user is trying to enroll into a WebAuthN MFA for a particular service, the user's browser that they're on generates a public and a private key pair. So this private key is actually stored securely on the user's device. So that could be your laptop or if you're using a security key, it's on the security key while that public key can be sent to the server. Now, the public key also, the server also keeps track of the public key, the user and the domain that it's tied to. When the user tries to access the app, so this is when the verification step is happening, the server sends a challenge to the user's device. It says, hey, prove that it's actually you. Now the user's device uses the private key it actually has on the device to sign the challenge. So only the device has that private key is unique to that user. Once that challenge is signed, you know that user is that user and that they're trying to access the site that they were actually enrolled for. So this creates a response. It's sent back to the server. Now the server has the information it needs. It can verify the response using the user's public key. And if it matches, voila, you're in. So that's how the enrollment and the verification for WebAuthN is working. So as you can see here, the credential key pair is cryptographically signed and the private key stored on your TPM, the hardware key, security module of your laptop, and also a credential key pair is tied to the specific domain, the website or the app you're trying to reach. So this mitigates that phishing attack because imagine like you accidentally fall into that phishing trap, right? No one is immune to that. So the user has your username password, they enter that, but they don't have your fingerprint. They don't have access to your device or the private key. So they actually cannot complete that authentication and their attack would be blocked. Yeah. And this is very familiar to me coming from the ops space, having used SSH keys a bunch, because public key crypto is really old and really well tested. Ops people have been putting up with the hassle of using it by hand, ever since SSH was invented back in 1995. And so just to make sure we're on the same page with the listeners about how public key cryptography works, you get this key pair that say a public key and a private key. What you do with it is that if someone knows my public key, I can use my private key to mathematically prove to them that I'm the same person who created both those keys together. But if that person only knows my public key, they can't use that public key to pretend to be the person who has the private key. So how it works is that there are some operations where it's really easy to check whether it was done right for a given set of inputs, but it's hard to guess what inputs would give you that output. The classic example is that it's easy to multiply two big prime numbers together to get an even bigger number. But if I just give you that really big number, it's really hard for you to figure out which two primes went into it. So historically, if you were using public key crypto, the systems that you use would handle some of that for you, but you were still responsible for generating your key pairs by invoking a command line utility with the correct options. And then your private keys were files on the disk and you had to keep those files safe. Most utilities encrypted your private key with a passphrase. But if someone got ahold of that file and they could get the passphrase like they did any other password, they had the whole key. Adding more keys also added to the work of memorizing more secrets in order to use your keys. So it made this really strong temptation to just use one key for everything. Just let's get everybody sharing a key. And then when somebody leaves, oh, let's just not think about that. So what I'm hearing from you, Megha, is that WebAuthN is making this public key cryptography super easy to use, often even easier than memorizing your password. Because instead of protecting the private key with a passphrase, this hardware security module is managing it. And it's only using that key when the owner does a physical thing in the real world, like pushing a button, touching a sensor, typing in their pin that tells them, yeah, it's time to use this key. And also, it's no more work to manage 100 keys like this than it is to manage one key. So WebAuthN gets to use a separate key pair for every single domain. And if you go to a domain you've never been on before that looks familiar, and it says, hey, you want to make a new key pair? Then that's a huge clue to the user. Oh, something fishy is going on here. Right, exactly. So you can see how complex things get, right? So imagine doing all of that every time you come into the office and you're trying to log in. So really, WebAuthN is all about creating ease of use and also high security because the phishing resistance is an authenticator, which is what makes it very unique and actually enables those passwordless experiences. So it hides all the details from the user. So like you said, you just bring in your touch ID and you're in. It's as simple as that every day. But WebAuthN in itself is actually split in two variations. One is your platform authenticators like your touch ID, Apple Touch ID, or your Windows Hello. But also the second one is security keys like your UB keys and Google Titan keys. So they work in slightly different ways. They have different assurance levels. And now with the introduction of past keys, this has become a little bit more complicated. And we are moving towards the concept of single device credentials, which are tied to your device and multi device credentials, which are actually in the cloud. So WebAuthN itself is evolving. Yeah. And with your hardware factors, your single device factors, you have the same headache we always had with SSH keys. You accidentally lose access to it. You misplace the little physical thing. You have to reset your computer or you get a new computer. You accidentally delete that file. And you were the only person who ever had your private key. You lose it, it's gone. It failed secure. So when things go wrong, nobody gets access. So I wonder if we can use this tech to fail safe instead, when striking more of a balance between convenience and security is appropriate. Could we use systems like this to share a user's private key across several devices or to help them retrieve their credentials if they accidentally locked themselves out? Oh, yeah. Good question. So for a long time, like you're saying, WebAuthN had not the best adoption for reasons because it was not easiest to onboard. Since for every new browser you moved to, you needed a new WebAuthN enrollment, a new device you moved to, you needed a new WebAuthN enrollment. And the same goes for recovery. Like you said, you lose it, you're out of it. So this is where pass keys came in. And last year, the Fido Alliance and a lot of the big camaraderie came together and said, we're going to solve for this. And what we are moving towards is something called a multi-device pass keys. And when we're talking pass keys, we're generally meaning multi-device here. They're just Fido2 WebAuthN credentials and a secure phishing resistant replacement for passwords. So that's key. It's supposed to be a replacement for passwords while keeping the security property of phishing resistant. Now, let me explain a little bit about what this multi-device means here. So what this does is that it means that your credentials can be backed up to a cloud provider like iCloud or Google Cloud and that it can be synchronized across devices. So here, your onboarding and recovery story just lights up. You can enroll once on my MacBook here and I can sync it to my iCloud. I can go to my iPhone and with the same iCloud, I have access to my WebAuthN credentials. And this makes it really easy to go from one device to another. And also, if I lose my laptop, it's okay. I can actually still access it from my iCloud. Now, what this means is we're preserving that strong key-based phishing resistant authentication model, but we are trading off some enterprise level security features such as now these keys are not device bound. So they're not stored on the device. They can be taken to the cloud and the attestations that we were getting from the authenticators before. They're not available in many of the cases. So as you can understand, we talked about how workforce use cases are around security and we do need a lot of these features like device bound and attestations there. Yeah, because if you have one key pair per device, then you not only know from the user side, this really is the same domain, but you know from the domain side, ah, this is not only the same user but the same piece of hardware that's logged on before. Yeah, because that trade-off for the convenience of pass keys is that the attacker can use those same channels to regain lost access that the real user would. So to get your pass key onto that new device, you've got to prove that you're you to that cloud provider's satisfaction, which to be fair is often good enough. Yeah, so that's right. Multi-device pass keys are still phishing resistant and way more secure than either password authenticators or legacy two-factor authenticators. So yes, they are good enough in many, many, many cases and if it might be the easiest way to move to phishing resistant. However, for more secure, secure conscious organizations, this is probably not going to meet the bar and this is where our security keys or single device credentials would come in. And also keep in mind that these multi-device pass keys are just as secure as your cloud provider access because you are going to store them there. Yeah, like if there's any workflow where a cloud-based, let's say email might be the single factor for gaining or regaining access, then as secure as your cloud provider already sets an upper bound on how secure that system's ever going to get. There's times when it's appropriate to not even allow self-serve email reset, which we see a lot in the more higher security, more corporate settings. But then there's also that trade-off of giving users quicker access to the things that it's worse for them to be locked out of than for them to take a little bit more risk on. So I definitely see how there's circumstances where that slight risk in favor of the huge convenience boost is worth it. And there's times when it's not. Yeah. Yeah. So if I'm a developer who's working with Okta, how can I add WebAuthn or pass key support to the applications that I'm working on? Yeah, so this is the same workflow as you would add any other tenecutor, which is to our Okta admin dashboard, or using our factors API. Both of those would allow you access to these tenecutors. This does fall in the MFA, AMFA skews. So you would have to have those skews as well. And can I restrict access to resources to require unlimited phishing resistant authentication? Absolutely. We have some great policy level constraints around our app sign on policy that has a great constraint that says you can only allow phishing resistant tenecutors, which will allow either WebAuthn or any other phishing resistant tenecutor. And you could even go more into saying that I want hardware protected and phishing resistant tenecutors. So we do allow that kind of flexibility in our policies. Okay. So that's all going to be at the policy level for whoever is managing identity at your organization. And as the person working on the app, it sounds like I barely have to think about it as long as those policies are right for the application. And I'm curious, Mega, is there anything that you're hoping will change within, let's say, the next few months about WebAuthn and PASCIs? Yeah. So multi-device PASCIs has been great for balancing security and usability. And I think it's great to get users into that passwordless phishing resistant journeys. However, it does, like we talked about, it does have some security concerns specifically for workforce use cases. So what we are hoping is to see PASCI providers to provide more controls and give access to attestations and metadata that help us discern more into if that authenticator is valid and if that device, which device was registered with that authenticator. So this kind of more information will help a lot of our workforce use cases and security controls. Oh, yeah. I see how the cloud provider will have a very, very good guess about what device the credential is coming from. Although, as you add that, you're of course adding another surface for attack. So there's going to be trade-offs for them and implementing it, for sure. And are WebAuthn and PASCIs the only phishing-resistant options that we've got available? No, actually, Okta offers a variety of phishing-resistant authenticators. So we talked about, obviously, WebAuthn and PASCIs, but we also have a smart card authenticator that we recently introduced, which is more for federal use cases, customers that use PIV. But we certainly have something called Okta Verify FastPass, which has all the properties of phishing-resistant authentication. It is our phishing-resistant authenticator, but on top of that, it also offers device context. So it's a great way to have the user context and the device context in one. So definitely meets a lot of needs for a lot of customers. Thank you so much. Thank you for joining us to share your perspectives and your insights into these technologies and how they're being used. Are there any other resources that you'd recommend for someone who wants to learn more about WebAuthn and PASCIs? Absolutely. Okta has some great blogs out there around phishing-resistant and WebAuthn and PASCIs, but we also have our Okta Help documentation, which has both the developer and the product documentation. So it's a great read to follow through on how to use WebAuthn. If you'd like to learn more about standards, the phytoalliance.org has specs around WebAuthn and more information around that. We also have the NIST standards, the National Institute of Standards. So that's a great read as well for assurance levels. Awesome. Thank you so much. So if listeners would like to discuss this podcast or if you have ideas for what you'd like to hear about in future podcasts, there will be a thread on the Okta Developer Forum linked wherever you found this podcast where you can talk about it. Thank you so much for having me. This is great.