mergeconflict268-1 === [00:00:00] James: Frank. I just found out that you are a security expert in the past. Is that the thing that happened? What happened? [00:00:16] Frank: Uh, no, I believe my word. Professional security person. As in someone was paying me to do security. I'd never set out as an expert. And I will never claim to be, I tried to read a cryptography book once and I got, I got through chapter one and two. Um, but then I gave it up and swore [00:00:33] James: I'd never read it again. My first job at cannon out of college, our database expert, Sean, he said, if you want to know everything about security and encryption, read this book, just, just like you probably did. Through chapter one. And then I said, public private tokens, handshake. I know everything there needs to be. So I'm a security, I'm a security professional also because I also read that first chapter, Frank, I bet it was the same book. [00:00:58] Frank: It probably was. And I'm just blanking on the name. It's a very well known book. Yeah. Um, I've also implemented my own security. I've rolled my own cryptography, which is something you're also not supposed to do, but at my really real job, it wasn't even like. Security. As in we think of it as in hiding information, it was more, uh, attacking API APIs and trying to break computers. So it's funny how security transcends like many topics. Uh, it can be privacy or it can just be making a machine explode or turn off or something [00:01:33] James: like that. Yeah. I obviously the most I've ever done is. Just public and private keys and I've interfaced with some things, you know, I've done some log-ins and my day I avoid all log-ins and my mobile application, and we've talked, we've done past episodes on, you know, fake security and fake login systems. My, um, user. Um, uh, animal crossing application comes to my [00:01:57] Frank: mind. I still like it. Somehow. We created a user system without users. I still think we should be proud of that. [00:02:03] James: I'm very proud of what we accomplished. I mean, it's a, it's a beautiful thing, right? You, you open the app and you're immediately. You're there. You already have an account everything's taken care of you automatically. We're we're great security, right? Professionals, Frank, but let's be honest. We're obviously not security experts and there's some amazing things that are happening in the world of security from a bunch of different companies. We, you know, we're like, Hey, we should try to get a security sort of. Expert, that's working on products in the real world to come talk to the merge conflict listeners. So I'm super excited to have one a guest, which we don't have guests on the podcast often, which means it's special case here. This is like, this is like never happens, but I'm really excited because Tanveer Ahmed who is a group product manager at Okta is joining us. And what's cool is that he. This, uh, working on building products, platforms and STKs for both enterprise and consumer focus on identity and access management that's as I am, I literally took that from his LinkedIn page and I don't actually know what any of that means. So Tanvir w what, what, what [00:03:08] Tanvir: do you do? Hi guys, first off, thanks for having me glad to be here actually at Okta, what I focus on is building out what's called our devices platform, and it's a new service, which allows. Both developers and, uh, end users and like enterprise settings to kind of have an identity for their device, uh, and, and have a way to kind of represent the device when you're trying to authenticate and make sure we have great experiences around that. So more specifically it's around like building great authentication experiences and making sure that things like which tokens to use and which cryptography, what type of cryptography to use is sort of abstracted. So [00:03:51] James: should you use Frank's cryptography? Is that what that's a good best practice. [00:03:55] Frank: It's really interesting because you said, um, device identity, and I've always thought about this for like the security of my apps. I'm like, can I make it so that only certain devices can talk to my API? We usually can't. So we do something like user security instead of device secure. And I forgot who told me, but he's someone at some point in my career said, device security is impossible. And so don't even try. So it's really funny that you bring it up. So is device security possible? Can you actually identify devices and control all that stuff? I'm so out of my league here, that I'm just fascinated. [00:04:33] Tanvir: Yes, you can. So what the team is building out here, uh, is a way to be able to kind of uniquely identify devices. And establish a sort of trust in an enrollment process. So in the onboarding process for devices you want to mark as trusted or belonging to you, there is an onboarding process that requires you to kind of prove your identity and the possession of your device. And with that, we're able to boot strap like a credential of sorts onto a device so that we are able. To, you know, trust it. But as you mentioned, that that problem is very hard to do. And so in many cases it does require a certain, you know, specialized pieces of hardware, like a TPM, uh, or some other secure chip on the device, uh, in order to make that. [00:05:23] Frank: James, I think we need a bell for TPM. It's coming up a lot these days. We [00:05:27] James: just did an entire episode on the TPM. Very excited about the TPM that I just installed on my computer. So it sounds like my device is super secure and ready to go. I guess, you know, temporarily when I think about device, well, not, there's just security in general. I think about authentication, right? Uh, inside my applications that I'm using every day, I downloaded from the internet. I log in with any of your name and password. And I maybe sometimes get a two factor authentication. Like why is that? Not just good enough? Like why do consumers, or even in the workplace need to be concerned about device identity? Like why, why is there this extra layer onto, on top of NYC? So [00:06:09] Tanvir: it's important to know which devices are being used to kind of access resources, both in a corporate setting and in a consumer setting, oftentimes devices, if they are left unmanaged by like an MDM or group policy, or if they're jailbroken or have malware on. If you give those devices access to your network layer, that could be very problematic. You never know. Who's kind of looking behind the scenes, even though an authenticated user, uh, is kind of using that device and is able to kind of say, yes, I am who I say I am and get access. That might not be what you want. Right. So it's important to not only understand the user, uh, who is claiming they are who they say they are. But also understand where they're coming from. Uh, not necessarily location or IP, but like the device they're using. Is it trusted? Is it managed? Have you seen this device before? Uh, is it not jailbroken things along those lines? [00:07:04] James: Got it. Yeah. So it sounds like the, when we think about identity and the device space, it's really that the device is secured and has the ability. To say, Hey, listen, company or service that I'm using, I've already preauthorized my, my device. So, you know, my device is, is valid and good going forward. Is that, is that kind of a safe number? [00:07:32] Tanvir: Yeah, that's a pretty safe assumption. [00:07:35] Frank: Sorry. Is this a PR I'm sorry. I'm so out of touch with the real world, is this a pretty common practice in most enterprises now? Is there 90% of the world? Does this a level of security or is this something that's growing right now? If [00:07:51] Tanvir: you look at the kind of roots of this problem statement, it kind of goes back a couple of decades to like domain joined days where in enterprise settings. Admins would want to domain join a device and kind of put their hands on it and put all of this group policy or management or whatever on that machine. And like really mark that device as like, yeah, I'm fully trusting this device. It's something I packaged my own hands and therefore it can now access secure corporate resources. And that's kind of in this paradigm, um, you know, for, for quite some time. And when you think about on-prem deployments, that's largely what that is. And what we've seen in the last couple of years is a move away from this like kind of on-prem centralized sort of a deployment model. And what we've seen instead is like, okay, well, anyone should be able to pick up any device should be a laptop. Uh, it could be something you go to a retail store, pick up a device or your own personal phone. You should be able to attest that this phone is mine, uh, that I am in possession of this device. And then it's a clean device by clean. I mean, it's secure, it's not, you know, kind of compromised in any way. And then you should be able to use that too. So this sort of a paradigm shift is what's causing more and more, I guess, products and services to come up in this space where we start solving the problem of, okay, now that the devices aren't being routed necessarily through a centralized authority, who's kind of, you know, physically joining the device to an on-prem server that they trust with their management and their endpoint security. How do we establish trust with these devices? And give them access to what we're, um, you know, trying to protect in our orgs or our consumer services is that [00:09:35] James: it sounds a lot like this is workplace only, but at the very end, you said also in the consumer space too. So for some of our listeners that may be thinking like, wow, this is just enterprise enterprise, enterprise, I'm shipping apps to the app store, or, you know, doing, you know, different types of deployments. Like how does this, this device. Uh, security aspect that you're talking about apply to the consumer space or does it, so [00:10:00] Tanvir: we, we think it does and we're seeing more and more interest from some of our consumer facing customers, uh, specifically in like finance and healthcare. And some other instances where even though it's a consumer facing app, you're trying to access equally sensitive information. So imagine you're trying to access health records. You may not necessarily want to provide them to a device that may be compromised. Same with, you know, think about like stock, uh, you know, your stock brokerage. Think about statements coming in or bank statements you do. You don't, you don't necessarily want those going to kind of compromise end points. Um, so it's coming up more and more in the consumer space as well. [00:10:40] James: Got it. That makes a lot of sense. I. Like I go through ups and downs of installing all my finance applications and then uninstalling all mine because I'm like, what if someone gets my phone? What if I get this? Like, all you need is my fingerprint. And then, you know, you're down the chain, you are logged in to all of my services. And if I have a, you know, a password app, That will pop up and again, you know, it takes one second to get in and then it fills in the passwords. And if there's an SMS, it just sends it to your phone. Like I've always found that, that to be a weird system. I understand the SMS process when I'm on a computer, like when I'm on my phone, I think it's really weird that I get an SMS to authenticate where I'm logging in on my device. That's amazing. It's broken. No. [00:11:30] Tanvir: Yeah. We sort of feel that way too, especially on my team. Uh, so my, my team really is focused around, uh, in addition to device identity, like proving the is proving and establishing the trust of a device. It's also focused around, um, this, this new type of factor we're calling, uh, Okta fast. And what Octa FastPass tries to do, is it installs a credential, um, on the TPM or the secure enclave of the device. Right. Um, and so now on your mobile device, if you're trying to sign into an application, instead of sending an SMS, which, you know, if you go to like a black hat conference or anything along those lines, like SMS can. Um, you know, compromised in itself, uh, with Octa FastPass, it's actually just having the application, uh, securely talk to our backend service as well as the secure chip on your device. Um, With a secure handshake and it kind of takes care of that key exchange for [00:12:32] Frank: you. I I'm very interested in, uh, the onboarding process. Cause I guess that's kinda where a lot of magic has to happen, where a token is generated. It's registered with a server it's stored on the phone and it's secure enclave. What are the kind of steps that are shared to, for this onboarding? I'm just really interested in how that goes. [00:12:53] Tanvir: Well, In our case, what we have is, uh, we let admins kind of define that experience. So it, admin can kind of create any sort of enrollment policy they'd like to have. So in this sample enrollment policy, they can choose to say that the device has to be within a certain network or a certain geographical location. Um, and also the user must prove their identity using, you know, certain factors, right? So it could be a combination of a password, or it could be that the admin themselves have to go and approve it. Um, but the idea is that once we have verified that, uh, you know, the user is who they say they are and they are in possession of the device, um, we actually use, uh, Some, I mean, I guess some of our own crypto, if you will, uh, from engineers who have read probably the same book, um, and come up with our own sorts of algorithms, like we then put a token on the device that we can then use to kind of sign further payloads, um, and prove the identity of that too. And [00:14:02] Frank: I would assume that that would be a per app kind of token because you're controlling one app at this kind of level for in, in the mobile [00:14:10] Tanvir: space, we should be able to kind of identify the device, uh, at an organization level. Um, so let's say you are trying to say that, Hey, my employer, um, this is my personal device and I'd like to use it for my work things. Right. That registration that you create, uh, between your device and your organization, um, through whichever app is actually valid for all other apps, you're trying to use to access resources in that organization, if that makes sense. So, so to put it concretely, if you register your device through, let's say an office app on your phone, um, As you're trying to sign in through slack in your organization, we would be able to recognize the device as well. [00:14:59] Frank: That's some fanciness. I liked that I had to, uh, I had to start up a new, uh, iPhone from scratch and I had to enter my password 8,000 times. And I kept wondering what in the apple security model prevents them from generating one token and having all their reps reference that. Um, I'm sure it's more complicated. Again, not as security expert. [00:15:20] James: Yeah, I guess what, why don't, why hasn't this sort of been a practice, especially in the consumer space, but in some of the enterprise, uh, space as well. Like why haven't, why hasn't this, you know, been the defacto. I think when I look. Some of the statistics. We look at some of the most recent hacks, right. That are out there. These hacks are just being done by simple passwords or old, uh, user accounts that weren't deleted. And they're being, you know, hacked by, you know, in foreign countries or whatever. Like why is it just really costly? Like, why hasn't is it hard to do? Like, you know, if Frank and I are independent Oliver's or we go and work at a company, like, is this hard to do? Is it easy to do? Like, why isn't it just the [00:16:03] Tanvir: standard? Yeah. That's a great question. Um, and I think a lot of it boils down to the technology available at the time. Um, so right now, uh, we're starting to see a lot of, uh, kind of development on this front from like apple and Google, you know, as the major us like mobile OSTP developer. Yeah, publishers, I guess. Um, you see apple kind of coming out with new technology somewhat recently, like, uh, they have this piece of tech called the SSO extension, right? Um, this SSO extension kind of allows one app to kind of talk to another. Uh, to be able to kind of share, uh, secrets and kind of share an authentication flow if you will. Right. I'm paraphrasing a lot. Um, but this type of technology hasn't really existed beyond like maybe a couple of versions of iOS ago. Um, and outside of this, if you think about it, um, apple in particular, they go to great lengths to make sure that apps are kind of sandboxed, right? Um, they, they can't really break out of their own sandbox. Um, so when you, when you think about it, it's like, how do you create this like seamless authentication experience, especially on mobile devices that kind of span across applications when they're sandboxed, if you don't get that OSTP level support. Um, so part of it is based off of, you know, what, what capabilities are we given from the operating system? And then part of it's also just that, like the. The authentication landscape itself is kind of adapting to this new sort of mobile first, um, you know, non on-prem sort of [00:17:45] Frank: world. Yeah. It makes a lot of sense. I would hate to have to join a network from France just to check my email or something when I'm not on vacation or something like that. Pretty interesting in that I I'm sorry. I want to go back to just one part where, uh, you are proving, you said you're proving that the device is clean. So we trusted on the network. It's running up to date software, or you can geo locate it, that kind of stuff. But you said there are still user credentials involved. And are these kind of a unified system, or is this like a user system talking to them? A device token system, are they usually integrated? Are they usually separate things that you work on? [00:18:27] Tanvir: So they're, they're slightly separate. Um, so the first piece in our kind of onboarding flow is the user has to kind of provide one their identifier. So. You know, typically that's like an email address, like potentially a phone number. Um, and they have to provide several factors that kind of prove their identity. So this could be like an authentication token given to them by a system admin, um, possibly a password combined with other factors, like a YubiKey of sorts. Um, so that, that kind of proves like the first bit, which is, you know, the user is who they say they are. The second bit is more around. Having the device kind of a test that it's not compromised in any particular way. So that can mean, you know, an enterprise scenarios. This can mean, uh, you know, Hey, prove that you are actually managed. Right. Um, and that could be like, provide me with some proof that you are kind of managed by some sort of MDM or group policy, entity, and. Kind of provide proof of that, or it could be like, Hey, can you attest that? You're not, jailbroken like solve this challenge or here pass our verification to prove that you are not rooted or jailbroken in any way, or Hey, prove to us. You actually have the most up-to-date antivirus definitions or that you have a pin on the device. Um, and so that sort of that verifying your device is not compromised. And only when you have both of those components, will we then do our handshake in our crypto to go ahead and install are not installed, but like, um, you know, provide you a key that you can use, uh, for further verification down the road. And [00:20:16] Frank: thanks for letting me know about that SSO extension. I did not know that that was added to iOS. That's a very good at them, especially because way back in the day we used to have device IDs and they used to be stable. That could have been a little something to add to that database, but those are gone. So at least they gave us, uh, extensions, I [00:20:33] James: guess. Yeah, that's, it's really cool because I actually have a blog post. I'm the most common things that I get all the time is like, I want. From from tons of developers, email me all the time. And they're like, I want to tie my user to a device, give me a unique device ID. Like, and I have a whole blog post that's like, no, you don't, you can't do it like that. Both Google and apple have done F because that unique, you know, device ID is. For the actual hardware that you're on is very sensitive if every single app has access to it. But it sounds like this is like one layer up. Right. Which is, Hey, the actual device. You know, itself like the, the, the, the, the cereal, the number is not necessarily important. It's that initial first handshake, which is like, Hey, we're coming in, we're doing this original sort of handshaking authentication. She's making sure the device is secure and assigning in an ideas is that credit you're basically assigning every device, this unique identifier, once it passes that. And then for the apps that are in the family of apps, if you're an enterprise, you might have hundreds of apps. Right? I think of when I take an Alaska air flight and there's literally, you know, they're, they're doing the checkout, they're doing the seat assignments are doing everything on an iPhone. Like you don't want to have to have them off into all 50 apps you want. To work seamlessly. So once that device is secure and unlocked, and I have no idea what Alaska airlines uses, by the way, I'm just using them as an example, because I'm an MVP gold, but, um, at least I was for the last two years, they brought it forward. I don't know about next year I went to zero travel. I've done, but really, really you're coming in and saying, Hey. You are assigning this unique identifier that then can be scaffolded out in use, and there could be multiple unique device identifiers. Then at that point, if there's different companies that are out there, cause I'm assuming that, you know, Octa, that the company you work for is not the only one that's trying to do this. Um, but the general. The idea is passing all that security, all that stuff to then give it this unique identifier that will live with it and continue to check up on it. I, I, I suppose correct. [00:22:48] Tanvir: Yeah. Uh, that's actually a pretty good way to. Um, so a long time ago, as you've pointed out, Google and apple both have, uh, stopped providing kind of globally unique device identifiers. So no longer can you grab, um, and, and actually pass and submit to the app store an app that fetches the UDDI, the ID, for example, and on, on unmanaged iOS devices. And so you run into this problem, um, you know, if you're trying to solve this use case of, well, how do I then identify these divides? Um, and that, that kind of boils into then the, the release of this like SSO extension, you can start doing things where you say, okay, well, here's this kind of central app, um, that you can use to kind of create this user app device binding. Um, I guess you can also throw Oregon there. Uh, so now you know that on this device, this user has authenticated through this application. Kind of successfully proven that, you know, they're this user on this device, on this app for this resource and now other apps on the device, if they're trying to access, if you're the same user on the same device, different app, um, you can have these apps kind of talk to each other now and reuse the same identifier that Okta provides. Uh, instead of relying on the actual device ID, uh, you know, the unique device ID that apple or Google assigned to that device. Um, and so it's, it's, it's our way of kind of being able to uniquely identify these devices without necessarily relying on any kind of identifiers that are provided in heart. Um, because the other really important bit here is like, how do we provide all this functionality for our customers yet at the same time, like maintain that user privacy. Right. Um, we, we don't want to collect information like location. Uh, we don't want to collect, you know, uniquely identifiable information. Like we're very sensitive to that. Um, and so. It is, you're totally on the, on the point here. So it's like, how do you provide that without, uh, collecting all this information? And it's like creating this model where you have this like one app on the device. That's now, you know, your gateway, if you will, for all the resources, um, that you want to access for that org and all other apps now need a way to kind of talk to this app as like a broker, if you will, it so that they can seamlessly get tokens without you having to. Kind of get an SMS every time we're typing your password. [00:25:30] James: Got it. Yeah. And I think one question that came up in my mind at least is. How do you convince, then I understand if, if the company assigned me a device, right? I'm like, here, here's your device. This is your work device, but nowadays you said it earlier, there's more people than ever with bringing their own devices. Right. And how do you convince them as a company or when you're picking a solution to trust us, say, Hey, trust us, right. We're not, we're not going to look at your emails. We're not going to monitor your traffic share. You're connected to our VPN. Like how, how, how has that trust built in to the system to convince people that it's okay to actually register their devices? Yeah. [00:26:16] Tanvir: So like the, the thing that separates what Octa provides here, um, or I guess like our implementation of this versus like what others have is that, uh, You know, unlike certain like MDM types of solutions, where they are able to kind of enforce certain policies or read, uh, information about you on your device, Octa doesn't actually even ask for any of those permissions. So if you take like a managed device type of scenario, so if you have. You know, some sort of MDM provider on the machine, what you'd notice as you actually have to install like a, some sort of profile on your device, um, which kind of gives it a little bit more, uh, I guess, visibility into the types of APIs that can call. So both iOS and Google have manageability layers, uh, which you can use to kind of get. Things like, well, actually you can get like serial numbers of the device. Um, but you can also enforce certain policy and read, uh, other things about the device. And so if in our case, like if we don't ask for those permissions, if you don't ask you to install a profile, um, whatever Okta is doing in order to kind of register your device and provide these like, kind of seamless authentication experience. Uh, it's all within the standard app sandbox that's available. Right. So if it's an app that's never asked for, you know, access to your contacts list, well, like Octa, nor your work has access to your contact list, um, nor does it have access to your photos or anything along those lines. Um, so it kind of inherits from the same sandboxing that, you know, the host app has, uh, So, I guess from that perspective, you, you sort of get that trust. The other thing is like, what Okta's providing here is very different from what a VPN is. So with a VPN, like all of your traffic goes through like a central, like tunnel of sorts and like typically your work or whoever will be able to kind of monitor the traffic that goes through that in our case. There's no, there's not necessarily a VPN involved. Um, Octa simply, uh, brokers. I guess the authentication and provides access to your resource. And then the, let's say you're trying to access slack, right? Um, you get signed into slack and then you're communicating with slack directly over your own cell network or your own wifi. So it's not like you're going through like a tunnel that, uh, can be seen by your work or Okta or anything on those. So [00:28:54] Frank: I assume as an app developer, if I was, let's say writing a server from scratch and I wanted all of these features, I assume my server would be talking to an Okta server or something at some point to validate whatever token that the phone rings back to me. Is that correct? [00:29:12] Tanvir: Yeah, so right. So your interactions with Okta would basically be, um, so we have several SDKs, uh, that you can use. Um, the SDK is basically determine how you want the authentication flow to look like in your app. So there's two models. One is a true drag and drop where you drop the SDK, you configure some parameters and Okta will draw the whole experience for you. Um, and we we'd kind of guide users through authentication. And then at the end of it, we just give you the app developer, a token that you can use to authenticate whatever calls you want. Right. The second type of SDK gives you like fine grain control. So it doesn't draw any UX necessarily. Um, but it gives you all the necessary headers and the methods you need to kind of build your own experience. So if you want to use native UI, instead of a web view, you can, you're fully empowered to do that. Um, think of it as like a two branches in the same kind of code path, because at the end of it again, you get like a token that you can use to authenticate whatever calls you want. Um, so that would be your interaction as a developer, right? You choose which deployment method you want and, um, use our stack to get the token you need. And then just. Go on and do whatever business logic you need to do. [00:30:36] Frank: Yeah. And I'm sorry, I have to go back to onboarding just one more time cause I can't get over it. Um, so I assume these tokens expire, I mean all tokens expire. That is the nature of the universe. Um, and I'm sure that's settable by policy. Typical expiration times for like, let's go back to the airline worker, someone who's actually managing data. What is a typical time to reprove that your device is clean and that you are who you say you are? I'm just [00:31:05] Tanvir: curious. Uh, so it, it depends, um, it can, it can be anywhere from like a year plus, but the thing is like, as you're actively using, um, as you're actively using that credential and you're using your device, Uh, we are able to kind of extend, uh, in a secure way. Yeah. The reenrollment process is a little bit, um, I guess it's a little bit challenging, uh, especially to, you know, more non-technical folks, right. Because it's like, oh, well, you know, I'm just trying to access slack. Why are you asking me to reprove that my device is good and that I am who I say I am. It's a little bit. Yeah. Um, and it's obtrusive to like add, you know, your actual assignment experience. So a lot of what we focus on is making sure that, you know, you got access to your apps as quickly and as seamlessly as possible. And that's not necessarily just like, you know, buzzwords, I'm throwing out. Like we actively sit down and try to think through like, okay, well to do that, we should look into how do we make these tokens long lived without compromising security? How do we extend the lifetime? How do we kind of make sure that users get that seamless and easy access? Yeah. [00:32:18] James: I'm, I'm curious here on the consumer space, because I'm definitely in the consumer space and, and the enterprise space too. But you know, you were talking about that. There's a lot of companies, especially in the financial area. Right? I think of, I use so many financial services all the time and the browser on my phone, everything like this. Are we going to live in a world where. I'm going to need to carry around a bunch of secure, like devices and chips and keys and everything to, to log in. Like, is there an extreme here in which to actually be secure, we're going to need a bunch of different ways to, to do this, or it's like, Hey, listen, you're a consumer James two factor authentication is just fine. You know, do it through an app or through your Google voice, or there's not an S you know, it's, you know, uh, a SIM card, uh, that can be swapped. Right. Um, or is it, or is it like, Hey, there's going to be a special segment of consumers that really want this, like, are we seeing consumer demand or is it like, people want it easy? Right. I think that's what you're, you're, you're, you're saying you said it right there, which is like, if it's too hard, people aren't going to want to do it. Right. That's the reason I don't work out as much because it's hard. And like, I know I should, like, I know I should care about security. I know I should totally do a bunch of crunches every night, but I don't. Right. I definitely care about security, but like, is it because there's like this additional layer to it? Like, you know, how do we, how do you balance. Yeah, [00:33:45] Tanvir: absolutely. Um, I would personally Howard, really not like, uh, to have to carry around a bunch of, uh, security devices, uh, just to be able to authenticate to the different services. Um, I mean, honestly, even using a password manager today for a certain services gets to be a bit much, uh, just managing all of that. Even the fact that a lot of it's managed through a password manager, uh, having to deal with that sometimes it's a bit much. Um, so like our general philosophy here is that your, your phone is actually very powerful. Um, and it's, it's pretty great. Uh, it has a way for you to provide biometrics and it has. Pretty top tier, um, security hardware already built into it. And if you think about it, your phone is probably the one device in your life that, that kind of knows the most about you. And like it's something that you own that you've kind of put a lot of your information into, um, and it should be able to be used to, to kind of securely identify you and verify who you are. Right. So in our kind of vision, uh, if you, if you look ahead your, your phone is that one security device that you'll ever need. Um, so you don't necessarily need to have multiple, your phone by itself should be good enough. And the experience, it should be good enough where let's say you walk up to your, um, you know, your desktop or your laptop, and you have your phone with you. You should be able to just open your phone, provide your biometric, and you should be able to sign it. Um, because from a security standpoint, that's, that is actually strong two factor authentication. Um, and as long as the bootstrapping mechanism is sound and you have the right crypto in place, and you can ensure that the device itself can be trusted, um, that actually meets all of the security guidelines that we have today. Uh, if you look at any of those security standards, we have like NIST or whatever, um, that, that meets it. And so instead of carrying around a bunch of devices, like we want that one device to be your phone. Um, and it's not just using your phone to authenticate into like a nest device, your laptop, your desktop, like whatever. Um, we want like, even within your phone, um, you know, if you're assigned into your banking app in the mobile and the mobile banking app, if you open safari and you try to sign into your bank, you should be silently signed in. It should be able to recognize that you're on the same device and that it's trust. You should be able to be signed in, but just providing your biometric. Right? So that's, that's the kind of world we want to, uh, go towards. [00:36:26] Frank: I want to live in that world. [00:36:27] James: Yeah. It's not the added complexity. Like I'm thinking about that might be the one-time registration system to get you in the codes, everything like that. But then once you're in the ideas, more seamlessly, I know we've all set up, you know, iOS and Android devices a bunch, and you go through this setting and that setting and, you know, part of it is signing into your account. And that part of just, Hey, I signed into my account once could be the thing. Now let me ask you one other question too. You know, what happens when you lose your phone or you drop your phone, it's made out of glass, everything shatters, like, you know, is there a way because to get to get back? Is it just that once I get a new device, how do I talk about the old device and do this other thing? And a case in point example is, you know, I had, uh, my, my partner, she, she, her phone slipped out and fell and it didn't shatter, but we took it to the apple store and they're like, yeah, just get a new one. We're like, okay, let's get a new one and backed up everything to the iCloud did all this stuff. And the one thing we forgot about was one of her, you know, off apps, you know, where it generates the codes nonstop. And man, that was just the biggest pain, which is everything is good. Until you no longer have that device, right? Like that device has gone. Apple has that device. They've wiped it from the planet. And now how do you verify yourself to PayPal or to your bank? You know, which we all know, none of us backed up our recovery codes. Let's just be honest about it. You know what I mean? You know, how does that interact in this, in this space too? Like, it's good once we're in, but what happens when you know it all, all it all goes to hell, you know? [00:38:09] Tanvir: Yeah. Yeah. Um, so there's two pieces to this that the team's kind of thinking through, um, there's one aspect where it's like, Hey, what happens if you lose your device? It could be that you broke it, or, you know, in a more nefarious case someone's, uh, Uh, taking it from your possession, I'll put it that way. Um, sure. Yeah. Uh, so in that latter case, what we're able to do is immediately revoke all the tokens that are used to kind of sign, uh, on the server side. Um, and so as soon as you recognize that the device is no longer in your possession or in the wrong hands, you'll be able to kind of make the tokens on the device immediately. It. Uh, so they wouldn't be able to authenticate into anything anymore. Um, the second piece is around, like, how do you then bootstrap a new device to now be recognized as your Newt, you know, your new device. Um, and the team right now is kind of thinking through, like, how do we provide like a secure, backup and restore mechanism? Um, I think for the time being, uh, we're still in a model where. You will have to at least go through at minimum, you have to go through the reenrollment process, uh, on that new phone. Um, but we're trying to get to a point where that's all you'll have to do. So it's not necessarily that you have to now go and, um, you know, re register your new device across like all of the different apps and services to use. It's just the one time I got a new phone. I just have to prove that this device is indeed mine. Once, and then once you do that, everything else now just continues working the same way. [00:39:52] James: Got it. Got it. That makes that makes sense. Yeah. I think that the. The system of reproving yourself sometimes can be the difficulty part, but that's literally what happens when you get a new device or go through different things. So that makes sense. I think [00:40:04] Frank: we're already feeling that with two factor authentication. It's why I keep two factor on a couple of different phones, because I wasn't as awkward situation where I lost the phone, where the two factor went to an apple was very angry with me and I had to get onto the phone with them and work it all out because the security implications said I could be cheating and all that stuff. But no, it was just a mistake. Um, so I think we're already kind of dealing with that and from everything 10 years described, I don't know. It sounds fine to me. I kind of want, I it's funny because I, I opened by saying none of this is possible, or at least I was always told this stuff is impossible and now I'm just realizing, oh, that was bad advice. Um, this is totally possible. As long as you have these policies and you don't make it too painful for people when they. [00:40:55] James: Yeah, it's only there's there's companies out there that are thinking through this product. So like, if I'm, if I'm out there developer, I could roll my own on everything, but there are a lot of best practices and industry standards and things that are emerging. It sounds like more than anything with Tammy. What you're sort of saying is a lot of this stuff is, you know, has it, as long as it's been around for 20 years or maybe some of the concepts have, but there's a lot of new things, new APIs opening up a new services available for developers to take advantage of that. Before we get outta here. I guess the one thing I would ask you and kind of a wrap up and close segment here is, you know, if I'm a developer, whether I'm in the enterprise or I'm in the consumer space where I'm just an indie developer, make an apps that do circuit simulation, who knows, um, what is like the one thing that you would want to like installer that, that you could tell that developer to think about when it comes to security online? [00:41:51] Tanvir: Wow. That's, that's tough. Only one thing. [00:41:55] James: Oh, sure. I mean, you can ramble it most [00:41:56] Frank: important thing now most, top 10 will make it even harder. [00:42:03] Tanvir: Yes. Like coming from, coming from Okta and like the types of problems that we kind of look at, um, I guess the most important piece of advice I would give is that authentication is hard. Uh, and it's probably harder, uh, than you would initially expect. Um, there's a lot that goes into really proving identity, uh, both for users. And now we are, we strongly believe that understanding device identity is also very critical in a lot of different applications and use cases. Um, and so to do that, right, I would highly encourage you to kind of leverage the work of not necessarily. Uh, Okta, although I will say like Octa and zeros services are pretty industry leading. Um, but to leverage some of these like great services that are available, because you, you got to leverage a lot of like the security, um, the kind of security and like the thinking that we've kind of already put into the authentication space and you get to kind of focus more on the actual, you know, whatever service it is you're trying to do. Right. Um, you got to have an app that is able to securely authenticate your, you know, way less likely to be kind of hacked from an identity standpoint. Um, And, and yeah, you, in most cases, you'll be able to kind of keep the same look and feel the branding, everything you'd like to have in your application anyway. Um, so that, that would be my, I guess, biggest piece of advice from a security standpoint. [00:43:37] James: Awesome. Yeah, that makes a lot of sense. I think that is coming back to Frank and I not being security experts and yeah. Well, I mean, you're a professional Frank you're professional. Uh, I, and [00:43:48] Frank: he just said we shouldn't have invented arguing based non user identity [00:43:52] James: system. Tanveer what we will send you the episode in which we talk about our good based security system. That's open source, which is nice. And it's clear it's it's okay. Here's here's how it works. Tanveer ready for this. Okay. So when, when, when a user opens my app, um, I automatically generate. Uh, some grids and I put that in the key chain. So put in, right, right in the key chain and secure storage on Android. Now the beautiful part about this user system is that as soon as they make a web API call, I, you know, encrypt that key. And I send that as a bearer token into my backend and both the public and the private and I, and I store that information inside of my database. Right. And I use that bearer token that that user has. Whenever they make a web request. And if there's a friend, let's say you're on, you know, you want to make a friend request. So you just give your friend your public key. So I can always look up people via their public key. And whenever I need to grab data for that user, we just make sure that that bearer token has the private key that's encrypted and the server and the app know how to like encrypt and decrypt accordingly. So it's just this very simple thing. And that's it. That's the user system. [00:45:11] Frank: How far back were you rolling your eyes during the week? [00:45:14] Tanvir: Um, what I'll say is it's, it's better than what I've heard. Other people implement. All [00:45:21] James: right. Security expert. That's what I like to say. Um, Sanford, thank you so much for joining us on this merge conflict and talking through not just things that are happening in the industry, because honestly, when we, we came in. Frank. And I were just saying, we were talking about OAuth and HTTPS for an hour, and I'm really happy where this wink, because it has me thinking about security in a whole different way. Um, where do, where do you want people to go to find you or the products that you're working on? You can make your, your plugs now, if you will. [00:45:47] Tanvir: Yeah. So, uh, we'll be talking a lot about what we're offering from Okta on developer day. That's coming up, uh, for me, you can reach out to me on LinkedIn. I guess that's the best way to find. Um, but yeah, uh, feel free to kind of check out what we're building on developer day. Awesome. [00:46:06] James: Well, I will put links to not only your LinkedIn, but also to develop a day, which is a free event happening and people can rewatch everything too, if they miss it. If they're listening to this podcast afterwards 10 period, thank you so much for coming on. Really appreciate [00:46:18] Tanvir: it. Thank you again for having me. [00:46:20] James: Awesome. Well, that's going to do it for this week's merge conflict. So until next time I'm James . And [00:46:26] Frank: I'm Frank Krueger. Thanks for listening. [00:46:29] Tanvir: Peace.