FIDO à la Carte

Can everyone hear me? There we go. Cool. Well thank you very much. Welcome everyone. It's all great to see you all here. It's still here. I guess it's the end, end of the day or end of the week. It's been a good week. So my name is Alexis Faulkner. I'm a authentication and password as product owner and never security. For those of you haven't have heard of Never Security before. We are a customer identity and access management based product company and we're experts in authentication. We have around 20 years of experience and in that time we've been protecting around 80% of Swiss transactions.

In our time, we've been working on time, some fantastic customers including UBS and general amongst many, many others. And I'm here today to talk to you around the various different Fido standards that exist and how you go about selecting the right one to meet your parcel's future. But I'll first like to start talking about Fido. I appreciate you might have heard of 'em a little bit over this last week, but I'll just cover the basics for you. So what do they do and what standards have they created?

So the Fire Alliance or an open industry association with a very simple mission to provide authentication standards to help reduce the world's over-reliance on passwords. They were formed in early 2013 by organizations including PayPal and Lenovo.

Today, their members include ourselves here at nevi, but also as you can see from the diagram here, a number of very, very big technology firms. Interestingly, they also include a number of certification bodies such as nist. I'm sure we can all agree that to get this level of support within such a short period of time, especially getting Microsoft, Google, and Apple, all of at table is exceptionally difficult to nature be applauded for it. So over their time, they've created a number of different standards.

They are the Fido Universal Second Factor or Fido, U2 F, the Fido Universal Authentication Framework or F U AAF and Fido two, two. Now I know a lot of you heard a lot about Pasky over the last few days, but it's worth just mentioning that technically speaking Pasky isn't a Fido standard, but it is built upon top of 5 0 2.

Each of these different standards have an associated certification with them and Nevis, we are of course FI certified and it's important to be certified cuz what you do is you bring confidence to customers when they're looking to purchase a password as product as each of the different standards has been scrutinized and reviewed by many people over a long period of time. So I'd like to spend some time with you now comparing each of these different standards and walking you through why you may pick one over another.

So I'll start actually by going through some of the comparison or some of the commonalities between the standards as they have a few. Firstly, none of the news passwords possibly a bit of a given with everything we're talking about, but I certainly think it's worth just calling out.

Instead, they utilize more modern technologies to perform the user verification process such as the use of biometrics. And they all work on the same basic principle of using public key cryptography to support the authentication process. But how does that actually work in practice? What does the public key cryptography process look like? This is where the user, or more specifically, the device will generate both a private key and a public key. The private key will remain upon the user's device must the public key will live on the services server.

It's important like this because the private key, not leaving the user's device means it'll never be seen by either the service or an A potential attacker. The second part is in the user verification side. This is where the particular device will manage access to that private key. Most devices will utilize some form of biometric as we mostly have these these days, but you can use a pin instead if you so wish. So if you now look at the diagram as a whole and consider it end to end, how does it work?

In actuality when a user tries to access a service, that service will provide a challenge to the user's device. The device can then be unlocked and the private key can be utilized to sign that challenge and provide it back to the service. The service can then use their publicly, confirm it's the user and ultimately allow them into the service if they are. What Fido has done by splitting this process up into two D two discreet sections is in essence they future-proof their solution as modifications to either side won't break that round trip.

So as new user verification methods become available, they can be modified and they can be added into the device. Equally as new authentication processes come about, like the post quantum encryption methodology, they can be added onto the authentication side, thus not breaking that end-to-end cycle. So that covers the commonalities that's now start to dig into some of the differences between each of these standards. So why would you choose Fido Universal Authentication Framework or the F uaf? The key part of this is you get control.

You get to control as a company the full authentication process from the very start to the very end. For instance, you're able to restrict the types of user verifications that users can perform, therefore enforcing that a biometric is utilized.

However, to gain this level of control, you will require your users to install an app. There are, there are options that most vendors provide, including ourselves at nevi, where you can use a pre-built configurable and tailorable app to provide you with the the means now and ultimately ensure a faster implementation. Conversely, if you wish to gain that extra level of control, you can use SDKs to implement into your pre-existing app if you have one or to use the basis for a new app as you move forward.

Secondly, from an industry perspective, if we consider financial services, F U F is the standard we'd recommend in this area. Currently, F U F is already utilizing the SCA process or the strong customer authentication process within PSD 2.0. For those who aren't aware what PSD two was or is, sorry, it's a seismic set of banking regulations that was brought in across the EU and the UK a couple of years ago to strengthen online support for consumers when using online services. Next Friday, UF also supports transaction confirmations, not only authentications.

What this means is as a user, as a user, you're not only confirming your, that you are aware of the transaction, but you are confirming the transaction in on itself that you are happy with it. Also, Friday F isn't just restricted to app and browser-based applications. It can be written into backend based services to support an authentication process there. So for instance, as a chat bot or as a call center, you can utilize fuf to perform authentication in those types of scenarios as well. Fuf also has support for older browsers and operating systems.

This is because F didn't have to me or the vendors didn't have to, sorry, I should say the technology firms didn't have to make modifications to any of their systems in order to provide access to F U F. It just worked. I'd now like to cover some of the different, now that's F u F covered. Let's now move on to F two and PA key. So everyone's talking about pasky. I've heard it a lot over the last couple of days and as I said before, it is actually an experience that's built on top of 5 0 2. But how does that actually all work? Let's start by covering what 5 0 2 actually is.

In general, Fido two is regardless of the successor to five U2 F as it now adds a password sets of features on top of that second factor experience already provided. 5 0 2 is made up of two other standards. CTAP two and web Orem where CTAP two is utilized to communicate to the other devices and Web orn is utilized to manage the challenges that a center received in that process.

Initially, 5 0 2 was designed for employee-based sign-in processes. This was possible as organizations could predict the type of hardware that their users have. Therefore they had a a, a predictable authentication process for their, for their users. But as we move into a consumer space, you can't conf, you don't know what sorts of hardware your users are gonna have. Therefore the authentication process isn't predictable in that same sense.

Therefore, it needed some additional features and this is where Pasky came in. Firstly, pasky keys are synchronized and they're backed up. That means that as a user, when I create my my Pasky on my device, it'll be synchronized, or sorry, I should say it'll be backed up to my ecosystem storage methodology. Therefore I can then utilize it on other devices within my same ecosystem in the Apple world, I create one on my iPhone, I can then utilize it on my iPad. In Apples world, that process utilized the iCloud service. Google has one similar, which is the Google password manager.

Each of these services are end-to-end encrypted. What that means is you the user have access to the pass keys, but Google, apple and no one else does. PAs keys can also be considered cross device, cross ecosystem, all of which can sometimes be referred to as a hybrid mode. What that means is if you are on a Windows-based machine, but your pasky already lives on your iPhone, the two devices can communicate with one another using Bluetooth or some sort of similar technology to allow the user to authenticate themselves on their Windows machine and have access to the service.

And finally, pass keys are also discoverable. What that means is if you've accessed a site or service on your app or your browser before, when you return to one of those places, that Pasky will be made available for you as a user to select, utilize and authenticate yourself onto the service. So there's PASKY and 5 0 2 covered, but if we now look at what the difference is between 5 0 2 and U A F are just a sec. So firstly, the benefits of 5 0 2, it's resistant to phish based attacks as the login is bound to that individual site.

If an attacker or the man in the middle directs you to a dummy site, that login credential will not work. 5 0 2 also does not require a second app to be installed on a device like U A F does. This means from a user and a friction perspective, the authentication and experience is significantly more seamless as users don't need to juggle multiple, multiple devices in order to do that authentication dance. But it is worth caveating that just a little bit at this point. Technology's still being implemented to all the devices at the moment.

Therefore this frictionless experience is certainly the future. But we can argue whether we are quite there. Yet these positives also have some associated downsides. As 5 0 2 relies upon the technology firms to implement it into their browsers and their operating systems. It means they get to control what the authentication has experienced for your own users organizations, oh sorry, unlike Friday Earth, where users can define what type of authentication mechanism they use in fighter two it will be up to the users, sorry, you don't get to control what method they use.

It will be up to your users. They could use a biometric, they could use a pin or they could use a secondary device in tiny. All of that is further complicated by the fact that laptops and desktops at this point in time may have a biometric or they may not. It's a very different and it's a bit of a minefield out there. So in what circumstances is 5 0 2 best place to be used?

Firstly, within organizations where employee, where to enable their employees to log in and in low friction based processes where high security isn't the defining factor, but getting into the services. The standard is starting to use by a lot of organizations at this point, including PayPal, kayak, and Virgin Media in the uk.

Also, Google have started to roll out for lot of air services in the last couple of weeks. The standard is somewhat at the early stages of adoption, but we do expect to see a lot of movement in this space over the short period of time as it has the backing from all the technology firms, apple, Google, and Microsoft alike. So with all of this information, how do you go about selecting one of the standards for yourself to actually use? The most important thing in all of this is you need to know your audience.

Both of the standards that I've discussed here can be the right, can be the right technology or the right standard to use as both have their relevant use cases and applicable cases. However, in order to select one, you need to know at least the following, how do your users access your sites? What are their needs and is there a consistency across the types of hardware that they currently own? So our suggestion when you're approaching this topic is to ask yourself the following four questions, are my users part of my workforce or are they external?

Do my users access the the service solely via web browser? Or do they use a mix of app and browsers? Does our service need to provide a transaction confirmation process and is there a, and do we need to control the user experience ourselves or are we content with the one that the technology firms is providing for us? There may actually be cases where what you really require is somewhat of a mix of all of these different standards whereby you need the convenience of 5 0 2 for access, but actually you still require transaction confirmations within your user flow.

Therefore, this one size standard fit all practice actually doesn't work for you. And in these instances, vendors such as ourselves here at Nevis can provide you with a solution whereby you can have that convenience of 5 0 2, you can have your transaction confirmations and you can manage it all through a single mechanism for convenience. So with that, I'd like to thank you for your time today. We at Nevis provide a lot of information on both our websites and through our blog posts. So please look us up and follow us. We're also here upstairs, outside the CO three room.

So please come and give us a visit. Have a chat. I know it's near the end, but we'll, we'll still be around for a little while yet. I hope you enjoy your final bit of time here at eic. I know there's not a lot left, but I look forward to meeting you all in the future at some point. Thank you. Thank you. So we have time for questions. If anybody has one, just raise your hand Regarding the 5 0 2 usage. How do you actually cover the recovery process if someone loses their authenticator?

So we have recovery methods that can be used through SMS style interpretations to recover the process, to recover those authenticators. They can be covered in the same way. Yeah. Anyone else have a question? Sure. You can turn on the other mic. I guess I decided You wanna use my asking a Question. This is basically not the question on your slides, but the general question that I didn't hear answered this whole week, everybody's talking about 5 0 2 and the security from the end user perspective. Everything up until the authentication is as secure as you can get it.

Of course the new attack vector is for hijackers to get into the session because they can't get into the authentication anymore. But the service side of things, no one's talking about the service side security because with a registration you're now inserting this connection between identity and public E and the well, when someone leaves the company, then you just delete that record. But who has got access to AC to that database? Because basically I just need to swap my public key with the public key of my boss and I've got his access.

What kind of security controls are being looked at in general to secure that side of things? It's just an question.

No, no, sure. You answer this week. So I think, I think like anything like when you've got backend based service, you need to have the same standard protection that you'd put in place and anything, you know, we confirm and manage the types of users who do have access to that database and we restrict a heavily, the database in on itself is put behind a number of firewalls. So they're ex explicitly very difficult to get to.

But management to the console and the application on itself can be controlled through these same similar types of methodologies to ensure that only relevant users have access to that service and can't, it can't be hijacked in that way. Okay, great. So back to my little question.

Yeah, so I remember that ever since Fido announced at the standard, I was like eagerly waiting. Like when can we finally reach the enough quote unquote worldwide penetration of the supporting hardware and stuff to actually make it feasible for customer facing websites as well. Are we there yet?

I, I think with the tech for 5 0 2, I think we, we are getting, there is the, the short answer that I, the, the technology firms, by them adding all the authentication flows in, yes, there's now the access to be able to utilize past keys now available for a lot more consumers than was ever there in the past. I mean, as I said, it is, and I've seen in other presentations this week, it is a little disjointed between those different ecosystems.

You know, each one is doing is implementing it, but how they actually liaise with each other and make sure that pasky are convenient between different ecosystems still has a way to go. But if you look at something like Friday uaf, the ability to utilize it, everyone has a mobile phone these days. Companies all have the ability to create their apps and many have of course. So the ability is there for something like five. You have to be initiated by any customer or organization at the moment to utilize that process.

Okay, great. Awesome. Any further questions from the audience?

If not, well thank you very much. Thank you Indeed. Very interesting. The future looking subject.