Oktane19: Does WebAuthn Signal the End of Passwords for Browsers?

Payal: So, today's focus is talking about web authentication, WebAuthn, and does it really signal the end of passwords for browsers? Now, before we jump into the web authentication piece, and how exactly it works, let's look at our favourite passwords and why passwords suck and also why multi-factor authentication, to some extent, sucks. So, let's look at some of the things there. Safe harbor statement.

Payal: So this is an email from a large financial company that recommends, how do you go about securing your password? How do you create a complex password with combination of letters, and numbers, and symbols, and it should be different from every different online account you guys have. So it should be unique.

Payal: And not only that, you have to change your passwords often.

Payal: Now what is wrong with this recommendation? I mean, it seems like a pretty reasonable recommendation, right? Now how many online accounts do all of us have? Like hundreds, right? How are supposed to remember unique passwords for all of them, and on top of that, change them all the time? Maybe every three months, or every six months.

Payal: Now this is where password managers, of course, come to rescue, but how many of us are actually using the password managers? What percentage of the population is using password managers? Very few. So this is one of the big challenges. So I'm actually sending this company Twitter messages to add MFA.

Payal: And then according to NIST guidelines, companies should not put the burden of managing the password's complexity on the consumers. And they shouldn't have to have change passwords often either. I mean unless there's a big breach or something like that and they need to go through that. Instead the companies should take the burden of managing and securing the access for those users.

Payal: How many of you guys have not showed up in this list yet? Please raise your hands. Please meet me outside. I'd love to know what you guys are doing 'cause this is like you have seven point some billion unique username and passwords already there, so it's like even if we have complex passwords if somebody's database gets breached your credentials are gonna show up here. So it really doesn't matter how complex your password's gonna be in that case. You're gonna end up here. And then what are the consequences? The attackers of hackers can basically get to it through, to take over your account through credential stuffing, password spraying, and then you have all of the phishing type of attacks too, right? Which doesn't even need this type of a database.

Payal: So this is a latest breach that I picked as an example. So this is the Citrix data breach that happened, I think it was around last month that it happened around December. And this happened because the attackers were able to gain access to the Citrix network through password spraying attack. And they were able to steal six terabytes of sensitive information.

Payal: What are the consequences of that again? You're pretty much getting a bad brand name, your customers lose trust, and then of course a huge financial impact, right? And to the users as well. Now your information is out there.

Payal: so what's the simplest way to mitigate these types of attacks? Well, you add multifactor authentication. Now what's the most commonly used MFA factors in the consumer websites? Even if you look at our financial websites today, most of them end up using SMS, but if you look from left to right we've got security questions, SMS, OTPs to like AD-based OTPs, push notifications, U2Fs, biometrics, there's all of these different types of factors.

Payal: So depending on the factor types, MFA is still hackable. And let's look at another example here. So I picked Citrix as an example specifically because one of the articles said that the attackers were not only able to get into the network through stealing bascially the password spraying attack, buy also able to bypass multifactor authentication. Now we don't have a lot of details on how they did that because Citrix didn't share that in their blog, but depending on the factor types, like I said, MFA is still hackable.

Payal: So let's look at some of the ways MFA can be hacked. So with SMS being the most common way to do MFA on the consumer websites, SIM swap has been on the rise. So SIM swap is where an attacker will basically pose as you through social engineering, then call your telecommunications company like AT&T, Verizon, T-Mobile, and then be able to convince them to swap the SIM card out and take over your number all together so now they start getting the texts directly and then you get disconnected from there. Reddit actually had an attack like this on their employee accounts, and so they basically were seeing some SIM swap attacks. And then also you must have read the news on this Bitcoin investor who was suing the AT&T for losing $23,000,000 in SIM swap attacks.

Payal: Even time-based OTPs, those AD-based OTPs can be phished. So we talked about different types of attacks here. Now this is where if a user in this case the attacker, sends a legit looking email to this user for an Amazon shipping. So he basically gets an email, he clicks on the link. And if you notice this is a fake website with two Ns, but everything looked legit, the email, the webpage looks legit, and the user does not notice the domain name there. So he happily enters his user name and password. Now what's happening behind the scenes is this attacker is proxying all the requests to the real website. And this is all automated, right. There's no one sitting in the back right there. And so the credentials are then passed to the real website. The real website asks for OTP. Then the attacker is basically requesting the user for the OTP, and then the attacker is able to get the OTP and take over the account. So that's basically taking over the OTPs as well.

Payal: And then we have these next generation types of phishing attacks with Evilginx. Now this is a man-in-the-middle attack where the attacker's not only able to get your username and passwords, but also be able to capture the session information like authentication tokens and session information stored in your cookies and completely bypass MFA except U2F. And I'll come back to that. But this is where the attacker does not need to create a fake website. They just leverage the fake domain name and then they basically have this man-in-the-middle Evilginx server sitting in the middle and it's basically intercepting all the information and setting that back to the real website. So from a user standpoint they are interacting with the content on the real website, but the domain name is not right.

Payal: And so how do you go about, I mentioned U2F is the only one that cannot be phished, so let's look at why U2F behaves that way and how it's resistant to phishing. So before we get into the U2F, I just wanna kind of talk about FIDO. So FIDO stands for fast identity online. And FIDO alliance is a open industry consortium that are focused, and they basically deliver simpler, stronger authentication. So public key cryptography-based authentication. And they have three different protocols. They have U2F, UAF, and FIDO2.

Payal: So let's look at how U2F works first. With U2F devices, they have the capability of storing, or generating origin-specific public-private key pair. And when I say origin-specific, it's actually the domain. It's tied to the domain. So if, now in the previous attack that we looked at at Amazon, it's actually when the user's registering to the real website. The public-private key pair is tied to the actual domain name there. So that's the origin-specific key pair. So now when the user is registering the new device, the U2F device as part of the multifactor authentication step, the U2F device sends the public key and a credential ID back to the web server and that's basically stored on the web server side.

Payal: And so when the user logs in, so that was a registration piece, right. And in this case during the registration the private key never left the U2F device by the way. So when the user logs in they enter their username and password, and then the web server sends a challenge back to the client. This challenge is a randomly generated string, long enough to not be able to be guessed, and that challenge along with the credential ID right, because it identifies what the credential ID for this origin is. And so it sends that, and then this client adds that origin ID and sends the challenge along with that to the U2F device. The U2F device then asks the user for the user presence, which means they have to tap on the device. It checks for the origin at this point as well, and then based on the credential ID and the origin, it then signs the challenge with the private key tied to that public key, and sends that signed challenge back to the server. On the server side, then the server verifies the public key, the signature basically, the value of the challenge to make sure that there was no man-in-the-middle there, and also the origin.

Payal: Now anywhere if anything fails, we know that we got phished. As and example, when the U2F device in the previous example where we saw Amazon had the wrong domain, if the previous example now the client sends a wrong origin information that U2F device is gonna reject that because the public-private key pair was tied to the real Amazon domain.

Payal: So that's the FIDO2, and I talked about UAF and, sorry. That was the U2F. And then I talked about UAF and FIDO2 as well. So those are again very similar based on public key cryptography. UAF didn't really gain any backing, but that was their passwordless approach to the same authentication mechanism. But that's where we have FIDO2 that came along too. So all of these protocols are structurally the same when it comes to using public key cryptography for authentication but there are some differences. U2F does not have a concept of a user. It only ties the credentials to the origin. So that's the problem with that which is why we can't do user verification, and so we cannot use this for passwordless. We have to use this only as a multifactor authentication or a 2FA.

Payal: Now this is where FIDO2 came along. So if you look at FIDO2, this is FIDO's passwordless evolution for FIDO U2F. It's a strong, simple, unphishable standard for secure authentication. FIDO2 comprises of two big components. You have the CTAP which is the Client to Authenticator Protocol, and that's basically a protocol that's, it's like a low-level protocol for communications with Bluetooth, NFC, or USB, to communicate with the authenticators. Then you have the web authentication APIs, and we'll talk about that too, but that's basically the interface that ties your web application to talk to the authenticators and be able to authenticate through the devices. So it's basically allowing your consumers, your users to be able to authenticate with the devices that they own, and authenticate into your web application. And then this FIDO2 server would be your web server, your web application that is FIDO2 enabled.

Payal: And so let's look at each of these components. I talked about CTAP. So that's the Client to Authenticator Protocol, and CTAP comprises of CTAP1 which is the older one, and then you have the CTAP2 which is the newer protocol as well. And each of these can, you can basically the communication mechanism is either through NFC, USB, or Bluetooth here. And when it comes to authenticators I've been just kind of showing you guys the U2F earlier devices, but there are different types of authenticators here. You have the platform the authenticators, and then you have the roaming, external authenticators. Now platform authenticators could be say your MacBooks or any of the devices that have like a biometrics type of authentication mechanism where when you log in you're doing a fingerprint or even on your other laptops where you do have biometrics type of a device. Even for Windows Hello as an example too. And then on your phone you have biometrics you have either touch ID or a face ID so that can act as a platform authenticator.

Payal: And then you have your external authenticators. Now these are devices like that are FIDO2 enabled, and they an ability of doing beyond just what U2F was doing. So they can also do biometric or they can handle the PIN. Even phones can be considered an external authenticators because they can then communicate with your laptop through Bluetooth in this case.

Payal: And then we have the web authentication API, so WebAuthn. So WebAuthn APIs are basically, they allow your websites to be able to authenticate using one of the devices that I showed you that the user already has. So it's a very easy way to authenticate without remembering any passwords. It is, think of that as an interface between your authenticator and your web application. It is a public key extension through credential management API. So for those of you who are not familiar with credential management API, you know when you log in to some of the websites and your browser keeps prompting you, "Hey! Do you want to store your password for this website?" That's behind the scenes using credential management API. So if you look at that when the browser's prompting your for "Hey! Do you want to store your password?" It's calling a navigator.credentials.store function and the credentials are your password, username and password. And when you basically wanna log in and retrieve the credentials from the browser's credentials storage then you're calling the navigator.credentials.get. And this works for federated identities as well.

Payal: So with WebAuthn the methods that we're using, the functions we're using is very similar. Now web authentication you're actually generating a public-private key from the authenticator so instead of a store, you're gonna say navigator.credentials.create and then the credentials type would be public key. And then when you're getting the credentials from the authenticator then you're doing a navigator.credentials.get with a public key. So that's the difference. That's how it's the extension to the credential management API.

Payal: So going back to web authentication, it enables strong authentication with public key cryptography and it is supported by all the leading browsers and platforms today. And I'll show you guys a whole list of browsers that are supporting web authentication today. And it is backed by big names like, Google, Microsoft, YubiKey, yubico, PayPal, Mozilla, all of them have backed WebAuthn.

Payal: Oops, wrong direction.

Payal: And in fact, just last month W3C and FIDO Alliance finalised the web standard for secure passwordless authentication with WebAuthn. So now WebAuthn is a standard for passwordless authentication.

Payal: Now enough about high-level, right? We wanna do deep dive. But before we deep dive into how exactly it works behind the scenes, let's just look at a quick demo.

James: Alright. So let's take a look at WebAuthn in action. So I am running on a Chrome browser here. Just the latest version of Chrome. And basically what we've done is we've created a WebAuthn demo, using the Okta Sign-in widget skin. So for those of you who are used to logging in to Okta you'll see the same look and feel. Except one major difference. There's a username field, but there is no password. So that's the whole purpose of our talk today. Eliminate those passwords.

James: So I'm going to as a user sign up for an account. And again, this reg form only has a username field, no password. And I'm just gonna sign in as the user nopws (no passwords), and hit register. And notice that WebAuthn is now prompting me to use either my hardware, Bluetooth, or built-in platform authenticator. Since I'm on a MacBook Pro I'm gonna click that and then you see that it's able to invoke a prompt through my OS and I can authenticate using my fingerprints on the touch ID. And just for one more safety's sake it's gonna, Chrome is gonna prompt me, am I sure that I wanna do this, and hit "Allow." And just like that I have been enrolled to this app.

James: So Payal that was awesome. How did that happen?

Payal: Awesome. Let's switch to the slides again. Oh, it's already there.

Payal: So what we're looking at from a demo standpoint, there's three components. You have the authenticator, you have your web server, your web application, and then you have the client-side web authentication API. Now when James registered, he passed the username no passwords during the registration. What the web server does at this time, is after it looks at the username it then generates a challenge. And when I talk about challenge, again it's a randomly generated long string that cannot be guessed, and it also sends the username and the relying party information. And this relying party information is information about the domain of the web server. Then on the web authentication site it receives that.

Payal: Before that let's look at the code here. This is an example. So on the client side, this is what your code will look like. You're gonna first check to see if your client supports web authentication. And if it does than you're gonna call navigator.credentials.create with a public key as a parameter. This public key has all of these information in the object. So it has the challenge that is received by the server, now this will be the actual value that has been sent by the server. I just have an example here just to show you how you would kind of randomly generate a challenge here. Then you have the relying party information which is the information about the web server, you have your user information which is the username. Attestation, this, attestation really means the server is requesting the authenticator to prove itself. So prove its integrity. So that's where the attestation piece comes into picture. This is typically kind of used more in the compliance based environments, but default attestation is set to none.

Payal: And then you have the public key credentials parameter. So these are the signing algorithms. So FIDO2 requires the servers to be able to support ES256, RS256, and then RS1 for backward compatibility.

Payal: And then this authenticator selection. This is pretty key. So when the user is tapping into these devices, touching the devices, the server is also asking that I want user verification as well, and not just the user presence. So I wanna be able to have something additional beyond just the tapping. I want the user to either do biometrics or I want them to enter a PIN depending on the device type. So that's where I'm saying, "Hey, I want the user verification is required." So this is what's sent from the server to the client.

James: So we built a handy little debug tool into our demo so we can actually see some of the data flow between the client and the server. So if I just go ahead on the bottom and expand this debug terminal. We should be able to see some of those messages that Payal alluded to. So as you can see when I signed into the app, I sent a message to server wanting to register under the username nopws. And immediately I received a response back from the server. Here was the challenge. The randomly generated string that Payal was referring to that I must now respond back to, as well as the encryption algorithms that I'm gonna use, and very important, this is the no phishing part of it. Here is the relying party, so when this credential eventually gets registered it's gonna registered under this domain name. And then here's the user ID that's the server signs that's associated with the username I inputted.

James: So Payal, maybe if you could walk us-

Payal: Yeah.

James: Through the rest of the flow here.

Payal: Yeah. So once the client receives this information then it adds the reliant party ID, generates an ID for the origin as well, and sends that information to the authenticator. So along with the challenge, username, and reliant party, that's sent to the authenticator. This authenticator like I said can be your phone, your like a FIDO2 devices, any of the FIDO2 enabled devices like the laptop as well. And these devices are capable of storing these credentials, the public-private keys credentials that it generates in a very secure manner either in the secure element, or TPMs, or a key storage, things like that.

Payal: So in this case what the authenticator is gonna do is first it's gonna check for the origin, then it's gonna ask for a user presence and user verification. So either with biometrics or PIN. And then it generates a new public-private key pair. It also generates an attestation object which is typically information about itself that it needs to send to the server to prove its integrity. And this is where the device would have its own certs along with that so it'll send some additional information about that. And then the user verification, right. And then what it does, it stores the private key and it generates a credential ID for this public-private key pair. And then it sends back the new public key. It also of course signs the challenge that was sent from the server with the new private key that was generated. So it sends the signed challenge, it sends the credential ID for that key pair, and it sends the attestation object.

Payal: On the server side, the server validates the signature with the public key. It validates the value of the challenge to make sure that that has not changed at all, and then it of course looks at the attestation object and verifies the authenticity of the authenticator, and then stores the new public key and the credential ID for this user on the server side.

Payal: So nowhere in the flow are you seeing any sensitive information being passed. The private key and the biometrics or the PIN, never really leaves the device, the authenticator that the user has, and the web server never has any credentials for the users that are stored. So that's when the registration is complete by the way.

James: Yeah. So once again, let's make sure we're seeing those types of messages in our demo here. So I've scrolled down in the logs in the section where we're sending the assertion back to the server for validation, the response to that challenge. So this is the credential ID that has been associated with my thumb authenticator, my touch ID. And then this is the attestation object which is this long stream over here. And this is the client data which is the signed challenge that the server would now validate to make sure that I'm responding to the original challenge that was sent. And once the server validates that, I get a 200 OK message saying that I've successfully registered.

Payal: And all of this information sent back is encoded. That's why you see those strings.

James: Yeah. Alright so let's maybe look at the other half of the flow which is the authentication flow. So I'm gonna hide my debug terminal here, and go back to my demo. And I'm gonna sign in under the same user name here, nopws. And once again, you'll see Chrome through the OS wants to validate my identity. So I will use my fingerprint on the touch ID. And just like that, no typing, I'm logged in to my application. Very simple app. Just a little bit of relaying back some of the data. So Payal if you could walk us through similarly the authentication flow that's be great.

Payal: Sure. So what you saw earlier was when James authenticated this time, the website actually remembered which credential ID was sent back, right. So we'll talk about that as well. So when do the authentication, now again, James sent the username this time. Now this time what the web server does, is it knows that this user is already registered, so it again generates a new challenge and it sends the credential ID that is tied to this username. Now there could be a list of credential IDs that the server sends, because you can not only register, you can register multiple devices in this case. So you can register you laptop, you can register your phone, you may have a FIDO2 external device. You can register that too. So it'll send a list of credential IDs and that would've prompted on James' screen to show, "Hey which one do you want to use?" Right. So it sends the credential ID back as well. So on the code side, as an example, it's gonna be very similar to what we saw on the registration side with of course some differences. So again you're gonna check if your client supports WebAuthn and if it does, this time you're gonna call navigator.credentials.get with public key options.

Payal: Now the options here sent with public key are you have your challenge that you receive from the server, again the value here is just to show you guys how you would generate one, but otherwise it's the value received from the server. And then you have this "allow credentials." Allow credentials is the list of credential IDs. So if you have multiple, it'll basically send the whole list of the credential IDs back to the client.

James: Great. So once again let's take a look at our demo log here. So right after our registration was complete, this line signals the beginning of our log in or authentication flow. So once again I am asking the server, I wanna log in under the username nopws. And I receive a response back from the server with my credential ID along with the randomly generated string which is my challenge. And of course once again very importantly the relying party ID which is the domain that I want to log in to. So back to you Payal.

Payal: This one? Oh, yeah. I talked about, I missed the user verification part. Again, the server is requesting for user verification here as well, that I want something like a biometrics or a PIN for the user to verify himself or herself. So then the client then passes all this information along with the relying party ID information back to the authenticator. The authenticator this time again check for the origin, asks for user present, asks for the user verification as well either with biometrics or a PIN, and so when James then taps into the device with his biometrics, the authenticator then also looks for the credential ID and of course ties, looks up for the private key tied to that credential ID, and then combines a couple of things and signs that those two information with the private key and sends it back. It's basically at this point is sending and assertion.

Payal: So just before that I'll let you, I'll show you guys what that is. So what the authenticator does, it takes that ClientDataHash that was received from the client, it's basically hash of the combination of the challenge and the origin information, and the credential ID, it combines the authenticatorData from the authenticator at this time as well. And if you look at the authenticatorData that quickly bunch of fields like the relying party ID hash, it has a bunch of flags like the UV flag which is user verification equals to, UP equals user presence equals true. And then you have the counter which is basically sent for more around reply attacks. And so what it does is it combines the authenticatorData and the information that it received from the client, which is the challenge and the origin and the relying party ID, and it signs them together with the private key tied to that credential ID that was sent to the authenticator and generates an assertion signature.

Payal: So that's the difference between registration and authentication. The registration it sends back an attestation object, and then with authentication it sends an assertion object back. And so all of this information is sent back to the server. On the server side, the server then validates the signature, it validates the value of the challenge, it checks for the user handle which is the user verification. It also looks at the authenticatorData and checks for like replay attacks and things like that. And then once it's verified all of this it logs the user in. And so this is just the response from the server saying that, okay all the validation expectations are true, and the user's logged in.

James: Yep. So once again we'll close out the spinal leg of the authentication flow. So this is sending the assertion back to the server. So here again is my credential ID associated with my platform authenticator on this device. And then here was the authenticationData that Payal was referring to earlier. Here is the ClientDataHash and a combination of these two plus my private key signing it creates this signature right here. And once the server validates that I will get a 200 successfully authenticated under my username.

Payal: So kind of going back here, right. When you look at all the security aspect of this. Again, just to repeat the sensitive information which is your private key, your biometrics, your PIN, never ever leaves the authenticator. There is no sensitive data going across the communication channels anywhere. And the web server is not storing any information. So anytime your user is authenticating with this, they cannot get phished at this point because really everything is tied to the origin and there is not sensitive information that they can steal at all.

Payal: So these are the browsers that support today. This is basically you have the Chrome Desktop, Chrome on Android, Firefox, Edge, and with Edge moving to Chromium I believe there's support in there as well. And then the Safari, it's in development mode, so it is coming soon. And IOS we still don't have support there but I've seen some experimental features available as well. So but there is a lot of momentum around the browsers supporting web authentication today.

James: So to kind of recap this session and summarise some of the benefits, WebAuthn is based off of strong authentication. It's based off of public key cryptography, and more importantly it is the standard now by the W3C. In addition though, in addition to being stronger than passwords or some of the 2FA factors Payal alluded to earlier, it also is really simple to use which means lower friction and ultimately more adoption for your end users

James: Also inheriting some of the best benefits of FIDO1, it is resistant to phishing, because again each key pair is tied specifically to a domain. And all of this, the combined enhanced security with the lower user friction with the resistance to phishing should result in cost savings for you if you choose to adopt this type of technology. Because we should see less password resets, less provisioning requests, and another side benefit of WebAuthn is because a lot of these biometrics are being built in to some of these platform authenticators and as Payal alluded to earlier there's a use case where you can use your existing mobile device and pair it via Bluetooth for authentication. It means that your consumers, or your end users will already have this technology in hand and they don't need to necessarily purchase something additional to be able to leverage this technology. So we think this will have the ability to scale and be adopted.

James: Do what does this all mean? We kind of teased the session with the question, "Does this mean the end of passwords?" I guess we have to answer that, don't we Payal?

Payal: Yeah. So I'll give my thoughts, but we'll love to get your thoughts and of course James yours too.

Payal: First impression, it's definitely looks promising. Right. I would love to use something like that. But I can see passwords kind of still clinging and hanging around. Some of the websites would want to do, before you register the user and the devices, you may want them to probably authenticate first in some sort of way. Like an identity proofing. It could be where the existing websites keep their passwords to start with, and then have the users register, and then move them off of that all together or keep passwords as a backup.

Payal: You saw this morning that we did a demo. You could also do some type of proofing with just a simple MagicLink. So we may not need passwords at all. So those are possibly there as well. And then also when it comes to browser support, there is still some work involved. Like with IOS it's such a widely-used device today, we still don't have support on IOS yet. So that has yet to come, but I'm hoping Apple will do some work there. And also when it comes to these types of devices, you know not all users may have access to these kind of devices that support. So like smart phones, or laptops with biometrics. They may be able to get devices outside like an external device like a yubico with PIN or something like that, but then they have to go purchase that. And not everybody would have multiple devices so they may just have one device, they lose it, they have to still fall back on something that would let them in. So there are, is still a ways to go, but definitely looks promising. What do you think, James?

James: Yeah I think there are definitely some good signs, right. Most users are used to the idea of biometrics. Today it unlocks your keychain which is your password and your real credentials. This is a much better and safer way to do things. But to some degree the user's already familiar with this type of experience. And also the increasing browser support is a good sign along with the standardization. But as Payal said, this is not gonna happen overnight. Not everyone is gonna have, especially on you wanna talk about desktop, have a device that has like a built-in biometric or platform authenticator. So we will see continuation of passwords until kind of the next phase of human behavior and hardware devices that support it. But we are also kind of interested in your opinion. If we go to the next slide here. And so please also share your inputs on whether or not you think passwords will be obsoleted by WebAuthn. But also we're also open to any Q&A and in addition to incentivise all your patience and for all your wonderful questions, we're also passing out FIDO2 USB keys thanks to our sponsor yubico. They have asked, if we can scan your badge in exchange for a free key. So with that, any question from the audience?

Payal: Oh wow. Lot of YubiKey folks.

James: Yes, right here.

Payal: And these keys support PIN by the way.

Speaker 3: I notice it's, that's loud, I notice it said it was resistant to phishing. I was wondering where there's still vulnerabilities.

Payal: That's a good question. I mean really it's more around, again, if your device is stolen, right? As an example. And if you don't have user verification, and it's just a tap, in that case because like I said you know if the server does not request a server verification and they still go through that and you still set this up as a passwordless, if your device is stolen say, your spouse or your friend steals it then they could still authenticate at that point as you. So that's a capability. That's why things like attestation, user verification are key to going passwordless here when you do these. And of course verifying everything on the server side as well, so you don't leave those holes out there.

Speaker 4: Hi, how do I sign on the same account with two devices.

Payal: So with two devices, so when you went and registered, you can go in typically, again, our example didn't do that, but typically the website would also require, like once you're authenticated you would actually, you should have a list of devices that are available for you, and you can go and add and register additional devices. And it should also like ask you for a PIN if you're registering like a YubiKey that supports the PIN. So typically the websites have to build that out.

James: Remember in Payal's code example, you had the credential ID which is associated with that specific, yeah, credential.

Payal: Yeah. So first time you'll just register one device, and then once you're in you have the capability of registering additional devices.

Speaker 5: Will this tie-in to the, during the keynote they talked about user behavioural functionality that's coming for the adaptive MFA. Will this tie-in to that so that if it's a, if for instance that like a lost key. Would it see that you're on a new device with a key that you already have and perhaps prompt for additional authentication as a result? Or is there integration that's coming for that?

James: Yeah, I'll take that one. Our session was meant for kind of just a more around the WebAuthn standard, but your question is specifically to the Okta product. So first of all I'd say in our security Roadmap session there was a previous one and there's a repeat gonna happen at 3:30, they're gonna cover WebAuthn implemented as part of the Okta Sign-in widget as part of our product. And as part of our product, yes you can do factor sequencing, which means based on context such as IP and device context, you can say forget the password go straight to the WebAuthn as the only factor.

Payal: And you can add additional factors as needed depending on the risk context of the user.

Speaker 6: So at the beginning you were talking about phishing, TOTP tokens. To HOTP tokens have the same kind of issues for phishing.

Payal: I would think so. I don't see ... pardon me?

Speaker 7: Everything goes back to 

Payal: Yeah. Everything pretty much goes to browser. Anything can be captured with the attacker sitting in the middle and proxying all the requests. It can just grab that information.

James: The user thinks its the real site, so they're giving you their real PIN. So, or the real OTP.

Speaker 8: To follow up on the registering multiple devices, so with this approach, how would one access an account from let's say a public computer or without having done all the legwork ahead of time to register more devices.

Payal: Yeah, when it comes to accessing from a pubic computer, right, that's gonna be challenging because it's not your device that you're registered with. You don't want to store your credentials on there either. That's where, I mean if you want to use and external authenticator at that time, that would be a safer approach. So if you are using a phone, in that case you still have to tie it with Bluetooth on your laptop, the public laptop. You may not wanna do that. So something like a YubiKey at that point with a PIN is what you insert and log in is the best way to go.

Payal: So that kinda counts as a limitation, right? When it comes to moving to WebAuthn, you do have limitations like these as well that we need to figure out.

Speaker 9: So, moving from a centralised authentication to a decentralised like device-based, so do you see any hybrid solution required?

Payal: Like we were talking about right, when we said the passwords may not go away. So there may be a hybrid approach where during the registration a lot of times you may want to register a device. Once the user's already known to you and have gone through some additional ID proofing, at that point you may see a hybrid approach where you still have a password at that point, but then you know once you do that, then you move away. And like he was asking the question specific to Okta, depending on the risk context, you know you may be like, "Okay, you know what? Even though web authentication is highly secured, I want them to go through some additional factors in this case." And password could be one additional factor, as an example. So yeah. There could be hybrid approaches in this case.

Staff: Great questions. Looks like we have time for two more.

Payal: And we're also looking for your thoughts as well, not just questions. So let us know what you guys think when it comes to going passwordless. We'd love to hear your thoughts.

Speaker 11: Hi. So WebAuthn is still a pretty new standard. What sort of developer support and libraries exist currently.

Payal: So for developers, there are libraries already existing. And there's like a lot of different examples too. But like I said, right, it's basically and extension for credential management API, so if you can just go to GitHub you'll find a lot of different libraries. And there's examples from Google, there's examples from yubico. So you'll find a lot of different libraries out there today.

Speaker 12: I uh, yeah. Are you aware of any existing published vulnerabilities in any of the authentication devices?

Payal: Mainly the one big thing that I've been reading everywhere is the user verification part. Is even though the user verification can be set to basically false or a zero, not required, that's when you shouldn't use the web authentication for primary authentication. I haven't come across any of the known vulnerabilities yet. Everything's been very positive so far. It's very new. But yeah, that's something that's yet to be documented or found.

Speaker 12: Things like weak key generation, like remote code execution on the keys themselves, like it seems like this has got a lot of potential, but with any new technology there's gonna be tons of implementation bugs and they'll be really severe.

Payal: Right. Yeah. So of course it depends on the authenticator devices as well, right. That's where they have to be FIDO2 certified or enabled at that point so they have to meet the standards before you can say that this is a FIDO2 device.

James: Alright, well that wraps up our questions. We do wanna remind everyone if you enjoyed the session, please give us some love. These survey scores do matter. And also, just a reminder that for those of you guys looking for more information, that Roadmap session all the way on the right, is gonna talk about Okta's implementation of WebAuthn. And unfortunately we had an overlap with the customer identity Roadmap session which was the same time slot as this one, but that will kind of give you more context in general about where we're going with our customer identity product. And also, on Wednesday at 1 pm, for those of you who are just kind of new to Okta's APIs and SDKs, Nate Barbettini our DevX product manager will be walking through kind of how Okta makes it easy to add authentication and user management to your applications as well as share a Roadmap for some of these items.

Payal: Yeah, in the morning session when we showed the ticket code demo, there was a part where the user logs in with the MagicLink, you can actually replace that with WebAuthn. And that's pretty much a passwordless experience there as well.

James: Alright, thank you.

Payal: Oh, thank you for coming.