Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
From Passwords to Passkeys: Exploring the Future of Authentication with Massi Gori
Play On
03 NOV • 2024
1 hour 4 mins
Share:
In this episode of Nerding Out with Viktor, Viktor is joined by Massi Gori, an expert in authentication and identity management, for a deep dive into the evolution and future of digital security. Massi, a veteran in the field and currently a product manager at Canonical, shares insights from nearly two decades of experience covering everything from legacy systems to the latest in passwordless technology.
The conversation begins with a look back at the origins of authentication technology, where foundational protocols like LDAP and Kerberos first addressed the need for secure, shared computing environments. Massi recounts the rise of SAML, OAuth, and OpenID, which paved the way for Single Sign-On (SSO) and federated identity management, now essential for secure, streamlined access across multiple systems.
Viktor and Massi explore the critical difference between authentication (establishing identity) and authorization (defining access permissions), explaining how each fits into the broader framework of identity management. Massi also outlines the importance of user management and governance, key elements in maintaining security at scale. They discuss the progression from early hardware tokens to today’s Multi-Factor Authentication (MFA) options, which have made secure access more accessible and manageable for users worldwide.
The focus then shifts to the advancements of FIDO2 and WebAuthn standards, which represent a significant step toward a passwordless future. Massi delves into how these standards work to enhance security by protecting against advanced threats like adversary-in-the-middle attacks. He explains how continuous verification through biometrics, behavioral analysis, and device-based security is central to the zero-trust model, which increasingly underpins secure access policies.
In the latter part of the episode, Viktor and Massi discuss the latest development in passwordless technology: passkeys. By combining the security benefits of FIDO2 with the convenience of cloud synchronization, passkeys allow users to maintain secure access without relying on traditional passwords. The duo compares the strengths of physical hardware tokens, such as YubiKeys, with the ease of use offered by passkeys, giving listeners a clear picture of the trade-offs between these options.
This episode offers listeners a compelling exploration of the latest trends in authentication technology, with insights on how companies can stay ahead of security challenges in an increasingly connected world. Whether you’re a tech enthusiast or a security professional, this conversation provides valuable perspectives on the future of digital identity.
Transcript
Show/Hide Transcript
Welcome back to another episode of nerding out with Victor.
Today I'm joined by Massy Gorau, who is an authentication expert.
Hey, Massey.
Hello.
Hi, Viktor.
How are you doing?
Good, good.
So I have been wanting to do an episode about authentication or authorization.
We'll dive into difference in a second for some time now, in particular in light of Paschi, which is something that has taken the world by storm in the last year and a half or so, I think.
So today we got to talk about all things authentication and maybe start a little bit with background on yourself.
Martin, you've been in this space for quite some time.
You work at Canonical, but talk a little bit more about your backstory and how you ended up in this domain.
Absolutely.
So by the way, first of all, hello, everyone.
I mean, it's a pleasure to be here.
So right now, canonical, I am a staff product manager looking after our operator framework, that is juju, but also our elements of our authentication.
So out of all the roles that I've done in the past, this is, in a way, the one where I've been like the least focused on the domain.
Having said that, my first foray in the world of software development and that he was now 17 years ago, and it was primarily focused on the area of authentication.
And I cannot say that I willingly, like, ended up in there, just so happened to be the, you know, once you join, like, a very large company, you're put on a project that happened to be in my case, Oracle access manager.
Like a product that is now defunct but still used to be very popular back in the days in the early two thousands.
And then, yeah, from there I sort of like taken multiple roles, first in the area of consumer identity, then more enterprise identity, then more on the governance side of the identity space, Porta Tokta and my own startup, and then eventually landed at canonical.
So it's an interesting subject, very niche, but yet kind of like a fundamental one for the whole world of security.
Absolutely.
It's one of those things that so much of the world stood back and still run on LDAP, right?
Oh, yeah.
I mean, and if you look at, I think that Verizon published their latest data breach report, I think they've been doing that for more than 20 years now.
And identity compromises, whether intentional or unintentional because of malware, remain still at the top of the number one entry point for data breaches.
I think it's far from a sole problem, as we will discuss today.
Absolutely.
All right, let's start with, I guess, a history lesson.
I think so.
Kind of alluded to LDAP before.
And I guess LDAP kind of is where a lot of authentication kind of started.
Maybe we start with there.
Or if you want to go even further back in history, I'm happy to go down there just to have some foundation here.
Yeah, I think that the.
I'm not an historian by any means, but the topic of authentication really dates back as the history of the first computers were effectively that needed to be shown in the beginning.
It's not like today where we have smartphones and laptops and they are ubiquitous, but they need to be shared between different people in research institutes and universities.
That's where the idea of having different user spaces came into the picture.
Now in terms of the protocol and names that everybody knows, if I'm not mistaken.
Good old days.
Kerberos.
I think it was an MIT project in the middle to late eighties.
I mean, probably definitely way before my time.
But in the war where Internet was not in the picture, I think it was the, and still is to a certain extent the de facto standard for federation.
Now, if we approach more of the, like early 2000, that's when the fundamental concepts of how you do authentication are you handle sessions.
The part like never really changed, but what changed was like a growing interest in establishing federation standards so effectively how to represent identity and authorization of a specific person or system across the boundaries of a system or the boundaries of an enterprise.
And so early two thousands sort of like saw the rise, or even before that, saw the rise of SaMl first, then first SAML 1.01.12 .0 and like Shiba La in the middle.
Those were the years sort of like where I started my infra into authentication.
But then at the same time, Openid and Oauth sort of like started gaining grounds all the way to the modern days were effectively, they are gaining ever increasing share of the market.
Yeah, open idea, that's something you don't hear about every day, though.
They had a very popular days.
It must been early two thousands.
There was a big wave of that.
And then it didn't go away, of course.
Still a big part of the backstory, but yeah, not something you're exposed to back in the day before SSO, you could do like log into webpage using OpenID, which is.
Yeah, I mean, I don't think that there are many companies that still maintain their OpenID servers.
Canonical does, that's all I can say.
I mean, which I find very, very curious.
But yeah, indeed.
I mean, right now, most of the sign in with x buttons that you see, they tend to use openid connect behind the scenes, with the exception of Facebook being a very peculiar case.
But that's a little bit of a different backstory of its own.
Absolutely.
All right, cool.
So we talked a bit about backstory, and one of the core concepts, I guess, in authentication, or permission structure, I should say, as a bigger umbrella term, is the concept authentication versus authorization.
So maybe we spend a few second minutes on like, why is it different?
What does it matter?
And why is it important to differentiate that term?
Yeah, I mean, I'm glad you asked, because normally when we talk about identity management, it's one of those terms where it means different things to different people.
Now, when I approach the subject with my coworkers or newer team members that are not necessarily exposed to the domain, I tend to explain that in my opinion, there are five macro functional areas that fall under the realm of identity management.
First one being authentication.
That is the act of verifying that the users are who they claim they are.
Whether they are like people or personal users, it doesn't really matter.
Then there is the concept of authorization that is sort of like the act of verifying what the person can do.
Sorry, what the actor can do, on which resource.
And I think that this is important.
So an authorization is nothing.
I have certain permissions, and these are ethereal or abstract.
Permissions are always to be tied to resources.
And even when you say like that, you install a new system and you have a super admin, that doesn't mean that, I mean, the person can still perform administrative tasks on all the resources of the application.
So again, important what you can do on which resource.
Then there is a concept of federation.
You know, that's what were discussing in the beginning, whether it is with Kerberos, with Samo, with OAuth and whatnot.
It's sort of like the act of representing identity information, whether they are authentication or authorization, across multiple system boundaries.
And I think that's also the area where there is the highest amount of standardization.
Out of those, then number four, user management.
Again, sort of like adding, removing access, permissions, identities and whatnot.
It is a part of every identity management system.
And then the fifth is sort of like what underpins all the aforementioned ones, and is the identity governance.
Right.
So the idea that is that especially in enterprise use cases, but also in personal one, you need to make sure that you have attribution and so that you're able to say who did what and whether that action was authorized.
Right, okay.
So we have like a bigger picture of these terminology because I think they are important building blocks for this.
So kind of SAML, which is, we also have single sign on where SSL maybe let's talk a few moments on like these building blocks, because unless you worked in enterprise or you build software for enterprise, SAML is something probably you never touched.
You should probably be happy for that.
But let's talk a bit about why, how SAML so is different, and the building blocks, what makes up the two of those?
Yes, indeed.
SAML is in a way the sort of, I want to say the granddaddies of those kind of protocols.
So it is fundamentally like a XML based protocol.
And the one that you normally encounter to this day is the 2.0 version of the spec, which was, I think became popular around 2006.
So there are a couple of.
So the way normally works is that there are three actors.
So the service provider, which is normally that, the kind of like the server that you are trying to get access to a specific resource, there is a user agent, which normally is a physical person with a browser, and then there is an identity provider.
That is the system where you prove that you are who you say you are.
Right?
So in the case of SAML, it's a fairly complex protocol with a bunch of back and forth and chapter that first happens between the service provider and the user agent, where there is a request for a specific resource that followed by a redirection to the identity provider, and then subject to a successful authentication request that responds in a specific like XHTML form that includes, as I said, like an XML structure with things that are called assertions that represent certain attributes of a specific person.
Those are things that sort of like need to be previously agreed upon between the service provider and their entity provider at the point of integration.
So like something that normally the system administrator configures a little bit before all of this dance, all of this back and forth happens.
And then you have two types of SAML, you have IDP initiated and what's the other one?
I'm blanking.
You have two types of SAML dances, right?
Yeah.
I mean, the most common one that you normally tend to find is the one where there is a user hitting a specific service provider.
You know, I have an application x, whether it is, I don't know, SAP for example, I want to be able to look at that purchase order, right?
So from my client, I'm trying to access that, and that's what effectively triggers the process.
Normally that is what we see.
Of course you can also have the reverse, but normally, I mean the whole, I mean, you do authentication because you want to get access to a resource that is owned by the something else or someone else.
Right?
Yeah.
All right, so that's SAML and then I guess SSO is the modern version of that essentially.
Right.
Which is what if you have login with Google or with Azure or whatever, that's essentially necessary and behind the scenes, that's oauth two, I believe it is.
That's for the actual authentication piece, right?
Yeah, yeah.
So today for the most part that is openid connect, which is like a protocol.
Like it is an identity layer that is built on top of O two, which is against like another important standard that started gaining ground in the early two thousand ten s to basically allow for delegated authorization to systems.
So if we go back to the beginning of the millennium, so the early two thousands, you tended to have OpenID.
Openid one.
It is different from openid connect.
I mean, I understand that they share the first part of the name, but they are fundamentally different protocols.
So OpenID was what, effectively what you were using to represent different identity across system boundaries.
OAuth was something that kind of like started initially as a separate project in 2006, 2007 where there were people from Manolia, from Twitter, from Google, they were getting together to sort of find the standardized way to saying, hey, just you want user to selectively give access to certain specific attributes to their profile.
I don't know if you remember like the early days of Facebook or the social media where you effectively were providing the credentials of for example like your email, for Facebook to recognize the word, your contacts.
I mean, horrible security.
Yeah.
I mean, now 20 years later, we say like, oh my God, what were we doing 20 years ago?
But yeah, I mean, back in the days I think that there was like a necessary solution to a problem that was how can I only grant access to my contacts but not everywhere else before the, you know, Facebook needed to scrape your entire, I mean, basically get access to your email in order to do that.
So that's why Oauth was like, it was primarily born out of that, out of that suboptimal experience.
And then because of the fact that unlike SAML that relies on soap again, people that have been in the sector for a long time know what it is.
I think they usually have a lot.
Of great hair, probably reason why neurosoftware.
Engineers, I don't think that they necessarily know what was so pace.
But the point is, it's something that wasn't very suited, especially for an API driven world, which is the one in which we live today or in the background usage AWT's.
And that is a type of format a technology that is sort of like way better suited for an API.
First word.
That is the one for today.
So that's why first people started to building o two before then, you know, the openid connect try to bring those two worlds together.
And right now I think it is, you know, if you go to ignite event, for example like the Okta developer conference, they will tell you that it is by far the most used federation protocol out there in the world, both in the area of enterprise and consumer identity as well.
And then Okta and authorshare is now part of Okta.
Right.
But they offer both.
I guess they kind of solve the problem of this dual world that we kind of lived in where you kind need to be both if you're building software, right.
So I can see firsthand, like SAML is still as painful of a protocol.
It is still very widely used in the enterprise realm, right?
Yeah.
And I think that's a primarily like compliance.
I mean that scenario is primarily not driven by compliance.
Right.
So especially in those large organizations or in government enterprises, there are this very complex, you know, control framework and this internal audit driven world where obviously if you try to explain to a non technologist, you know, option a and option b, they both functionally do the same thing.
So why do we need to evolve, you know, even if the world, even if there are like very competitive reason to do so?
So I think that's, that's what we are seeing.
But I also think that as like Oauth opened the connect, it's also bridging into the world of servers and on devices.
I mean, you see that, you know, for example, a little tv and Google box behind me, you know, those frameworks, they are much more flexible.
Right.
And I think that as more and more use cases, especially like CLI based use cases or I places where you need robotic access coming to the picture, they come under the supervision of internal audit apartments.
I'm sure that will also shift away because doing those making the top an under SAML is, yeah, huge pain.
I mean, that's a very good point.
In particular, when you start to issue service, like you say, like survey service accounts for IoT devices and so on, where that's not really compatible with the SAML life cycle, which is very person heavy.
And then as part of, I guess, authentication, MFA or multifactor authentication or two FActor authentication has become, I mean, has been a thing forever in the enterprise world.
Like, if you worked for any security oriented industry for the last 20 years, you've probably had some kind of hardware token that you had to carry with you to log into your systems with.
In the last ten years, I guess it's become more common for people to understand, even though they don't really understand it behind the scenes.
But Google Authenticator was probably the one that, well, is one of the one that people still have got introduced to the concept of two fa with.
Right.
So behind the scenes it's using, I think it's top t, Google Authenticator.
So maybe talk about top t and hop t, which are two of the most common rolling past, rolling tokens, I guess.
Yeah, sure.
I think that we owe it to the, let me just say, the big companies out there, the massive educational, sort of like role that they've played to make millions of normal people and professional alike understand the importance of all of that.
Now.
I mean, whether we are talking about the underlying protocol, I mean, the, back in the days, I think were all using the little like RSA keys, you know, that the sort of like underlying technology or the algorithm side of it that hasn't really evolved.
I mean, that's not necessarily a bad thing because, you know, it's something that has been working for a long time and still, just like everything else, insecurity is about not building an impenetrable wall, but building a wall that is high enough that discourages people to sort of like try to jump over it and maybe go to our neighbor and try to do the same thing.
Right.
So, you know, like time based, like MFA tokens, I think that they have their value and they represent like a significant step up, especially compared to, the username and password.
But however, if we look about, if we consider them in the context of today's world where you have, what you're seeing much more and more like adversary in the middle type of attacks with, that are very easy to automate at scale.
Like if you, I don't know if you're familiar with frameworks like Marina or evil jinx, I mean, just to name a few of the very popular ones, they are not enough, right?
And it is, I don't want to say very easy, but like not very hard to sort of like synchronize these protections and effectively act on the next weakling of the chain that is stealing cookies and sessions.
Right.
Because oftentimes we forgot that those sort of like opaque tokens live for a very long time in our browser.
Right?
I mean, yeah, you're absolutely right.
It's about raising the bar.
Right.
But I think that's.
It's good that we start to see more acceptance of that and understand that.
But I remember when I first moved to the US, I grew up in Scandinavia and hardware tokens were a thing like in the early two thousands.
All the scandinavian banks used them back then.
And I remember moving to the US and I, I signed up for the bank account and it was just like, oh, here's your username and password.
I was like, but surely there is more protection to my actual bank account.
But no, that was like essentially thing for us, banks, like, they are order of magnitude behind when it comes to security.
And obviously two factor raised the bar there a lot.
So going back then to.
So we have rolling tokens and then that's something.
Well, it goes back to the fundamental principle behind MFA and two FA, which is something you have and something, you know.
Right.
Which is the building block for a lot of security.
Yeah, I think it's.
You tend to talk about the three.
The three main factor, right.
So there is like knowledge, right.
That is the password.
Like the password is something, you know, there is the concept of like inheritance.
That is something that you are, right.
So like the fingerprint, your face and whatnot.
And then there is the concept of possession and the hardware tokens in the case, or whether we're talking, I mean, those yubikeys or something that they tend to like, at least loosely, sort of like fall into their broader category.
And the idea is that, I mean, having two or more factors sort of like, tend to be like.
Tend to present a much higher wall to an adversary.
That doesn't mean that all second factors or all factors are created equal, right.
There are obviously ones that prefer that present a much higher assurance level.
And by the way, the concept of assurance levels, inauthentication is something that you can research about.
It is a formalized console, like what constitutes like a assurance level, like one or two of a specific authentication.
But again, I think it's a kind of like academic compliance concept, but nevertheless an important one to mention.
And so that's why after those hardware tokens, companies like, I think that there was duo Okta, Microsoft, they sort of started coming out with their own authentication apps, which in a way, they were a way of presenting a richer picture of the authentication event.
So adding just not two point in time signals.
I mean, the password, boom, input, it's a post request.
The TOtp, it's a single post request.
But maybe if you have an app on the phone with sufficient permissions, you can sort of like for example, understand or also log what is, whether the IP address is consistent with the one from the browser.
Right.
I mean, is the phone in China and the person in America as an example?
Or likewise, there are in certain cases also certain behavioral data points that are added into the mix.
Right.
So the accelerometer, was it recording the phone going up and down or sitting on a desk or.
So?
Again, I think that the point is it's all about, just like with everything in security is do I have reasonable assurance about a certain specific event?
And what is reasonable?
The idea is that as time goes by, that what reasonable is sort of like keeps going up.
Yeah.
So you kind of hinted at the whole zero trust model where you have to use behavioral metrics and to figure out if something makes sense.
In the case of Google, with their beyond the core, they drop permission if they find that you are not passing all the checks and having that kind of, that's a very sophisticated level of permission which most companies will not have the resource to do.
Well, I mean, you say that, but I don't fundamentally agree.
Right.
Because I think that those kind of frameworks and technology, I think that they, thanks to companies like Cloudflare, that not affiliated with me, but I'm a big fan of their technologies.
I use them for my own lab or tail scale or whatever.
I think that they present some very cost effective and extremely capable solutions that also offer a relatively shallow knowledge barrier to entry.
As an it administrator, they would like to adopt them for the users.
And another crucial thing, they don't get in the way of the day to day activities of colleagues and employees in China.
Yeah, don't get me wrong, I'm a big fan of both tail scale and offcloudflare, and they have definitely reduced the barrier to doing zero trust esque workloads with mtls and all those things.
But, yeah, so the lowest barrier is of course some kind of rotating token or soft token, and then if we go one step up to there, you have the hardware token.
So you mentioned Yubikeye, also a huge fan of Yubikey.
I'll be using them since I think I got, they sent me like a beta version of the first Yubikey, for whatever reason, way back when, and I've been using it ever since.
And we use them at screen that we use them.
Everybody uses Yubikeys for anything to get into our systems and they've kind of gone into a standard now.
So there's some gold feedo alliance, right?
Which standard I think they standardize under web auth end.
Is that correct or did I get that right?
Yes.
So if we talk about, and then I, you know, let me first address this point and address the benefits of it.
So when we talk about Fido, we are really talking about two parts.
So we are talking about setup that is sort of like the underlying protocol that enables the communication between the client and the authenticator.
And then Webauthn, which is the API layer.
So it's sort of like API that allows web application to leverage setup and utilize authenticator for user authentication.
Now, normal users, they don't necess, I mean you and I as end users of the technology, we will never interact with setup.
We will see like we will participate in the web auth dance.
But it's all, I mean, I think it's useful to understand the distinction between the two because in the, let me just say, many years in authentication has been around for a very long time and this is the most effective initiative that we as the companies had to unify around a specific standard.
So just to explain it with analogy, I think that the one that is normally presented is, I mean, if you want to do like an online food order sit up, it's sort of like the phone line that connects you to your favorite pizza place.
And then webb ten is sort of like the pizza menu, right?
So that allows you to sort of choose what is the specific food that you want for your route.
Now in terms of the benefit, was the first part of your question, in addition to the standardization, there is at least like one security and one privacy element that I want to mention.
So the security one we discussed doing adversary in the middle attacks, even when there are hardware tokens or authenticator apps, is becoming more and more commonplace.
And as I said, there is lot of automation for even novice wannabe hackers to pull it off.
Right?
So the great thing about Webautin and Fido is that the origin is a part of the challenge response mechanism.
So even when you are doing this, let me just say, transparent proxy style attacks, the system cannot be gained that easily, effectively because it is one of the elements that are exchanged between the client and the backend API.
The second part is the privacy element is a little bit of an interesting one because it really depends of what we use to store our passkeys.
Generally speaking, it adds a layer of opacity to your credentials.
Now, like having said that, obviously if you do value convenience, that might not necessarily be the case if you use Google or Apple or all Microsoft sort of like those platform to sync, you know, pass keys across all of your device.
I'm not saying that is insecure, and I don't want to suggest that data is misused, but it might be.
Again, those are things that the fact that it doesn't happen today doesn't mean that it might not happen in the future.
So if you're a privacy conscious person, this might be a better choice.
But for hardware tokens in Webauthn, ASCII is next generation of that.
So the initial feeder was just physically hardware tokens, like Yubikey style hardware token that you have to present.
Then it has some kind of string it returns.
So you registered your passkey in there and then Passkey is the next generation that we are exposed to.
Now let's come back to that part, because I'm curious about, and I have a lot of things about passkey.
I wanted to focus on the hardware tokens out of that first, which I think is different from the passkey part of it.
Yep, go for it.
So you had the web offend, which was Yubico.
Yubico, the company behind Yubikey, was one of the first, one of the guys in that, and became an open standard.
You could today buy a kind of a federated compliant device.
Then there was Fido two.
I don't actually know enough about the difference between Fido one and Fido two.
Is that something, is there any worthwhile conversation to have about those two?
Or.
I mean, I think that it's a set of like subsequent iteration on the idea.
And the point is that if you look at the Fido project, I mean there are.
It is an umbrella that actually includes different standards and specifications.
So to the point about.
So there was the beginning of it was the universal authentication factor at UAF was proposed, I think 2014, 2015 or something along those lines.
And together with that there was the U two f, the universal second factor, sort of like spec, which informed part of the FIDO two standard that came around a year later.
And the idea is that sort of like a single project or initiative split into two, which are the two ones that I mentioned before.
So the FIDO two that then resulted in the webo ten draft, that is something that is shepherded directly by the WTC and the SITA was the sort of way to standardize the communication, like the protocol that standardized communication between the client and the authenticator.
So I think it's been like an incremental, an evolution journey of a concept.
So what we have right now is fairly stable.
Right.
And I think that like empirically I don't have hard data on this, but like as an end user and consumer, I see it adopted on more and more websites.
I remember in the beginning it was just like only a few enlightened people, like companies like Google or PayPal, they were sort of doing that.
And now, I mean, even my italian bank, as you can imagine it's not at the forefront of technology, is actually doing it.
Yeah, think that.
And that was great.
Like they raised the bar significantly.
Now, you could still argue that this is still very tech product, right.
It's something that companies would issue and very few consumers would go out and buy because if you want to buy Yubikey, they're pretty expensive for like a consumer.
Like very few consumers buy.
I think they're like the five c.
I think they're like $70 or something like that, right?
Yeah, I think all of us have like a very powerful and capable device that we carry around everywhere we go in our pocket.
So, yes, I mean, you obviously us as technologists need to be aware of the trade off that we do when using, let me just say, our Android net perform to as a credential wallet, like if you can call it that way.
But fundamentally it is.
I think that also from a user experience perspective, again, I'm nothing, I'm a backend person, I'm not a uxer.
But the simplicity, the simplification of especially the registration part of the user journey is immense.
You don't have to create and remember secret, or even for example, registering TOTP, there needs to be sharing, even taking a picture of the QR code or entering the password, depending on what you use, still has a much higher friction than right now.
Clicking a button and putting a fingerprint or Face ID, it just reduces the number of steps.
And the easier it is, the more normally users and clients a certain service can register.
Yeah, you can't touch on something before, which is one of the issues with Yubikey is that if you lose it, you're kind of screwed unless you have multiple.
I use them extensively, I have three of them, I think, and I have backup keys that are locked up, but I am fully aware of that.
That's hardly how the average user would treat their authentication.
Obviously, I have a lot higher stakes with my systems than the average user too, of course.
But the trade off, as you alluded to, between having this cloud sync between your devices is tremendously valuable because if you lose your phone, you can still recover this because you can sync it up.
So that, I guess, gives us a good segue into passkey.
Passkey.
How is that different from a technological perspective, from Fido and that umbrella of a hardware token?
They share a lot of similarities.
But let's talk about first of all how they are different.
If you go for this standards that are tensor, if nothing, hundreds of pages.
I mean, you sort of like find the seeds of that, like all the way since the very beginning.
I mean, the point is that when you complete, like especially with the current, with the current standard, when you complete your registration, effectively, your authenticator stores a set of information.
So your credential id, your public and private key, I mean, in this case, for the specific service user information, I mean, like your information, and crucially, like a domain name, that is what gives you the resistance to adversarial in the middle attacks that are like becoming more popular these days.
Right?
So I think that it's a way to standardize something that, let me just say, some public key cryptography methodologies that have been tried by several different companies.
So fundamentally it's different because you have, it's a public private key arrangement rather than a second factor authentication keys.
Just for the avoidance of that FidO, two keys and pass keys, the same thing.
It's just like a different way of calling.
Okay, fair enough.
Right.
So, but you, it's important.
For instance, with the Yubikey, it can do Fido too.
With passkey, however, I think it only has like five or ten slots, I believe.
I guess it depends on which model they buy.
I mean, yeah, you know, they definitely, I mean, there are different makers and right now that are also like a yemenite.
Again, if you don't like Yubico, there are a lot of like white label providers that are, I think I remember like seeing on GitHub, like open source projects of like, if you want to do and create your own.
I mean, so I think that the DIY enthusiast market is.
Right.
Yeah.
My criticism was not against Yubico and Yubikey.
I'm a big fan of them, but rather the fact that because of the fact that you enrolling, you're rolling a separate key pair per service you're authenticating with, you have constraints on the device versus in fido one, you have the same two factors, so to speak, against every service you enrolled it against.
Right.
And that's a big distinction in how they work.
Yeah.
So, I mean, I'm sure that there are in the works or there are like in the future sort of like ways to standardize, like how you do the syncing of that.
I mean, but just like with every.
Every standard, like, it takes multiple iterations and especially with something that is so security sensitive before that sort of like, gets adopted by multiple people.
Having said that, it is an interesting standard.
It would be interesting to have a look at the actual adoption.
Right.
But, you know, already the fact that we.
I don't think that there are like any more sensitive, you know, websites that only username and password, I think that's already like a very big win.
Right.
We are obviously like five to ten years ahead of what the general public will see and we're experiencing their day to day life.
But I mean, we are unfortunately still seeing customer or still seeing websites using SMS as a two factor authentication, including all the UK government services, which is not great.
Right.
At least in the UK compared to the US, we are less aggressive in recycling phone numbers.
And I think that is, again, there is the spoofing use case, obviously.
But like in the US, this is even like a much more problematic because in the space of literally a month from when you stopped using your or you stopped paying for your phone service, someone else might effectively have it.
That's very interesting.
You're still subject to Sim swapping, though, which is a whole different attack vector, which is probably a bigger reason to not use SMS in the first place, to fa because.
Yeah, terrible for that reason.
All right, so I won't go further down the path key route because I think there's a lot to unpack there because I think it's a paradigm shift in how we do authentication because now you don't really have a username and password as you used to.
You now have a.
Well, from a technical perspective, you have a public key pair, even though the end user would never know that because it's all obfuscated from you.
But that means that you create a much more seamless onboarding flow for end user.
In particular on iOS, I don't know how it is on Android because I've had android phone in a while, but on iOS, if you go out to a website, you sign up with Passkey, you say create an account and that's it.
It doesn't ask for a password, it doesn't ask for anything.
That's it's done with the flow that's available across all my iOS devices.
I think that's such a faster shift that I think adoption has been really rapid in the last passkey is only what, two years old if that as a standard.
I think a little bit we need to double check, but like, definitely, like a little bit more than that.
I think that the latest setup, I think it was approved in 2018.
So I mean, it's been okay, fair enough.
Okay.
Yeah, it's been a little bit of years, right.
But it's also true, I think, that there was around the same time probably when like secure elements were being installed on, not only on phones, but also on laptop and windows.
Hello.
And whatnot.
I think that they, like, everything sort of started coming around the same time.
Right?
Yeah.
And let's not forget that it's not just a matter of like the capability of the device, but as an application developer, right.
I mean, you need to have the right set of libraries, the right set of SDKs, and potentially the system that you're using needs to enable the use of that technology.
So there are a chain set of dependencies that to be considered when it comes down to the adoption, 100%.
I mean, at least as an end user, what I've seen last few years that you definitely see the massive push for passkey because I think it just makes sense from an end user's perspective.
And Apple obviously doubled down on passkey relatively recently.
One password, they've been pretty aggressive on getting their passkey support.
So that's something that's been prompted with.
And now you're almost in a problem where you have a problem dealing with where you store your passkeys because now you have multiple places where you can store your passkeys.
So now you're almost back to password management, but with passkeys instead.
Right.
But I mean, it seems like that's going to become the norm I think, going forward.
And I think it's a very welcomed transition for authentication because it raises the bar significantly for an attacker.
Right.
Yeah.
Now, so this is on the concept of security.
That is something that, I mean, personally it's very dear to me, but, and I think like also to many of the people that are reading this, that is also like the privacy angle.
And I think that there are like two, let me just say two elements that are not necessary, that are not directly addressed by this as an authentication standard, but they are more in the realm of federation that we don't talk about it enough, but we probably should talk about it a little bit more.
And the first one is sort of like the traceability and the linkability from an identity perspective that is done either the identity provider side or let me just say on the underlying party side, the kind of place where the application that you want to access.
I mean, so those are whether we are using username and password or pass keys or something like that.
They are sort of like two macro problem categories that for various reasons they don't have a clear path or a clear solution to that.
That's a very good question because I never thought about that, where it's like who actually manage identity of pascuas?
If I say I'm foor.com, who can verify that?
Because I can issue a token against that.
And then you would enroll the public token so the authentication dance would work just fine.
But I.
There is no verification flow against that email address or whatever identifier you're using.
How is actually the identifier stacked in that scenario?
Because that's an important one.
I think it's more about the fact that whether we like it or not, there is a large amount of consolidation on the identity provider side especially.
I'm talking about the consumer identity use case, not for enterprises but for, let me just say, people shopping around the Internet and whatnot.
And so there aren't a lot of players in that space.
The market is fairly concentrated.
Yeah.
And again, I mean, you know, I'm not suggesting that anyone is acting in bad faith or whatever, but first of all, there are threat actors and you never know where the information might end up.
And then second of all, the fact that something isn't happening today doesn't mean that it might not happen in the future.
So you have this sort of like fairly large players that have a lot of information around like our behavior and what we do and the websites and where do we authenticate to the point that potentially don't say they could impersonate you, but they could know a lot on the ten.
And by the way, the same happens on the other side.
Right?
So if there was a large enough number of colluding relying parties, again, you might potentially be able to profile or understand a lot about the behavior of a single specific person by his or her own activity on such websites.
And I think that the main enabler for that is that regardless of what you use, you know, the way normally works is that you would use a, like a passkey against Google or against, you know what, zero.
Ok, pick your favorite.
But then that system would be federated with the actual system that you're trying to access by means of, you know, potentially like a o two token, which is something that wasn't really, it was designed with previous in mind, but with the different type of previously.
Right.
So it was differential access to information rather than kind of like non leaking details about, let me just say about the specific user account or the behavior in aggregate.
All right, so in that scenario then my identity provider that I'm issuing from this, from like Apple or Oct zero or Okta, they are the one that I'm communicating with.
And then behind the scenes it's then probably oauth two.
Right, okay, that's interesting.
And that brings us into like Passkey in the enterprise.
Well, right.
How would a scenario like that work?
How would, well, let me ask you a different question.
Is passkey something that can replace SAML or SSO or would it sit on top of that layer as identified prior to the SSO?
That's, that's a very good question.
Right.
So it's not going to replace it.
Right.
Because if you recall the macro functional areas that we discussed at the beginning of the episode, puskies have very much to do with authentication.
Right?
So with the way you prove who you say you are, which, you know, whether you use Okta, whether you use, I don't know, keycloak that you sell for whatever your sort of identity provider of choices, that's what you use against that.
And then the how, you know, keycloak or Okta or whatever, Google communicates certain information about yourself like the groups that you belong to or whatever, to the target system.
That is where SAML comes in.
That is where OAuth comes in.
What I can say, I mean, like one of the things that I've tried to push really hard at Okta in particular is just making sure that those fundamentally web standard, they are also adopted on servers in particular while the web application world as you know, evolved and sort of like keeping the pace with the general consumer world on CLI based applications.
And also like when you authenticate towards servers, the user experience is very poor right now.
Yeah, absolutely.
And that usually sort of like you normally need to operate a trade off between, let me just say, having a good user experience and compromising on security in the sense of like how do you connect the two systems?
So again, on Azure, for example, you were able to use your Azure ad credentials for a very long time rather than a certificate to authenticate to the servers.
And now, I mean, every Ubuntu server from 2404, for example, every ubuntu server in the world is also able to make sense of a JWT natively, meaning that you can use the device flow, which is what you use, for example, to authenticate to Netflix on your tv or Disney plus whatever.
You know, the sort of case where with the second device you either take a picture of QR code or you put the URL and then you input the challenge.
So you can sort of like use the same mechanics to reuse the same credentials that you have in your enterprise identity provider.
So in your opt in your Google Drive, rather than a certificate that is managed completely independently of that to authenticate to your servers.
And that applies on the CLI when you're doing openssh sessions and whatnot.
So I think that privileged access management or access to back end infrastructure is right now where I personally see that we need to step up.
There is a lot more to be done to bring the same assurance level that we have when we authenticate to Salesforce or SAP.
Also, when you authenticate to that, rather than resorting to esoteric VPN's and all that stuff only frustrates users.
It's a really interesting one, right?
Because the server application world is done very differently.
It's usually like, I mean, we use h keys usually to manage access, which then in turn needs to be managed.
And if you're a really savvy SOP, like I know, Facebook or meta, for instance, they use PGP keys for authentication over Ssh with like time expiry and all that stuff.
I mean, I personally think that the best solution is openSSh certificates.
So that is what I wish more people knew about it.
Oh, sorry.
Yeah, that's what I meant.
So openSSh certificates, I mean, they are great because they also allow you to encode what are the commands, for example, that the user can.
So that's there, but like setting it up.
And I think that whenever you have multiple authoritative source of identity, I think that's where there is a much higher risk of things getting out of sync.
And what happens when there is a lever or a mover in the enterprise.
While if you can centralize, if you can make it easier for extremely overwhelmed with a ton of different tasks to take care of this specific issue, I think that, yeah, I guess it's fundamentally.
Different thing between the web and the server is that a server needs to work in offline mode.
And that's where a lot of the off flows break.
If you can just make an API call and see.
Is this a valid claim?
Relatively straightforward.
But if you have an outage and your network is down on your server, or your egress is down, your Internet link is down, you still need to authenticate to that server.
And I think that's what makes a huge difference because it needs to work in offline mode.
I mean, though, the big, the optimist of the world, they all have their own proxy solution.
Let's say you're using one of those.
You always have the sort of solution that do a certain amount of sync and replication offline.
So that's fair.
But even when you're using OpenSSH certificates, for example, you will normally resort to something like vault as the store, the database sort of for that.
So I think that similar challenges applies.
There are obviously cases where you literally have just one server in the wild disconnected for everything.
Yes, but I think that those are more niche scenarios rather than the, I have my, I don't know, vMware, Openstack, whatever sort of like infrastructure.
And I need access to that.
I need to distribute keys.
I need to tell like Joe can only access one, two, three and marry four, five keys.
And that's, I mean, I know tailscale got some offerings around that.
I haven't toyed with that, but I know they have like an sh, you can sh through tailscale and they issue keys for you, which I presume are short lived, but I haven't actually looked at that.
That's an interesting one, because what they do is effectively they spin up like a goss server in the back.
They don't use the native opensSh server of the host, but they actually spin up their own one, which is what they use to effectively do all the dance that their solution does, which I think is, again, it's very interesting, it's not too dissimilar from what Cloudflare with access is doing on the ran call for the.
Whatever it's called.
So those are, they are like interesting solution.
They take in a way that they kind of like detach a little bit themselves from the server, but they bring like an exponentially better user experience to the mix.
Yeah, I mean, I like that approach because essentially then passkey becomes your source of truth, if that makes sense.
And then you issue, based on that, you issue a short lived token, which I mean, let's be real, a lot of people, even developers, they don't even have passphrase on their sage keys and nor do they rotate them very frequently.
So one of those has saved keys leak and game over.
You have production access.
Right.
So if we can enforce more short lived certificates, that's a massive win for security, right?
Yeah.
And I mean even if you want to live in the like, in a world of just opensSh Certs manage vault because you know, you don't want to try this sort of like new age, you know, passing JWT's to servers because it's too novel, you know, for you.
I mean like Vault does offer integration.
I mean I don't know which one is in the free version, but definitely all of is in the free version, meaning that you can federate it with your identity provider of choice.
Let's say it's Okta and you can use, you know, pusky is a talk that, you know, unseals the vaults, gets you desert and whatever.
Yeah.
Everything else sort of like happens after that.
Right.
So there are ways and I think that from a company perspective it is a no brainer.
They should be used everywhere else.
And I think again, pass keys in conjunction with an identity provider that is federated either directly with the server or with something like vault for back end access, you could achieve the same level of security, obviously just load inserts on yubikeys.
But, but again, revocation management at scale when you have a thousand people and whatnot, I think it suits more individual use case rather than an enterprise one, in my personal opinion.
Oh yeah, no, I agree with that.
Even PGP, which kind of the gold standard of security that's been.
There's never ever going to die, it's managing that as an individual is hard if you want to do it right, but trying to do that at scale as an organization is extremely difficult.
So absolutely, you don't want to have to fly in everybody to do key signing parties and whatnot, because that's probably not the best use of your company resources.
So absolutely, if we can fold that into.
But it's interesting how these actually come full circle with server management and how that ties together.
I never actually thought about them together, but actually tail scale is actually in a very unique position to actually do something really clever on that.
Even though I guess Google could as well if they wanted to for that.
Yeah, yeah.
I mean the Google doesn't offer the server component in their commercial option.
I think that they are like Yamcorp Zero Trust solution is a lot little bit more focused towards web use cases.
There are a lot of companies, I mean, you know, Calfare and TeSL, they are the two names that are on top of my mind.
But again, I'm sure that there are a lot more and as I said, we've taken a similar but different approach where we use the openssh, we use a component that talks directly with palm, with NSS to sort of like make that negotiation happen if we're talking about obviously Linux server in the case.
But fundamentally I do believe, and as canonical we do believe that's where the world is going.
Right.
Because ease of use wins over everything else always like no matter what session, right?
Absolutely.
All right.
That's something I would curious to zoom in on at some future point because I never actually played with that side of the server.
But that's interesting to see that there is stuff happening around that as well because I think, yeah, hopefully the days of managing users with ansible puppet or chef and the likes off are over.
It's never fun.
Marcy, this has been super interesting to me.
I've learned a lot about these topics and particularly how both server management and how Fido and all these thinking fit together into a wholesome strategy.
So I think if there is anything else you want to add before we wrap up.
If not, I think it's been super help for me and I've learned quite a lot.
Yeah, I mean it was great to talk about, let me just say this new set of trends.
I think that we didn't talk about it because there is a lot of heterogeneity in the area of authorization.
And that's another interesting area that I think it's ripe for change, maybe for another day, but representing authorization as a directly seeker graph rather than a tree, I think that's, that's part of some sort of like new wave of solutions that are coming onto the market.
Again, spirited by Google and one of the research papers.
But nevertheless, I think that's another, that's another interesting topic.
But I'm sure that, you know, you can pass along some links or whatever, just make sure that there is enough reading material to compliment on that because very interesting.
Very like, you know, beer nerding out sort of conversation topic.
I intentionally left out the whole topic of service accounts and I am because I think that's a topic by itself.
So I intentionally left those topics out.
So perfect.
Again, thanks much for coming on the show, Marcy, I really appreciate it.
Thank you so much.
Likewise.
Have a good one.
Found an error or typo? File PR against this file or the transcript.