The Changelog: Software Development, Open Source - Over the top auth strategies (Friends)

Episode Date: January 31, 2025

Dan Moore from FusionAuth joins us for a wide-ranging discussion about modern auth strategies. We talk magic links, OTP, MFA, passkeys, password managers & so much more.

Welcome to Changelog and Friends, a weekly talk show about arm wrestling truckers. Thanks as always to our partners at FLY, the public cloud with push button deployments scaling to thousands of instances. Learn all about my good friend, David Shue, over at Retool. Now, David, I've known about Retool for a very long time. You've been working with us for many, many years. And speaking of many, many years, Brex is one of your oldest customers. You've been in business almost seven years. I think they've been a customer of yours for almost all those seven years, to my knowledge. But share the story.

What do you do for Brex? How does Brex leverage Retool? And why have they stayed with you all these years? So what's really interesting about Brex is that they are a extremely operational heavy company. And so for them, the quality of the internal tools is so important because you can imagine they have to deal with fraud,

they have to deal with underwriting, they have to deal with so many problems, basically. They have a giant team internally, basically just using internal tools day in and day out. And so they have a very high bar for internal tools. And when they first started, we were in the same YC batch, actually. We were both at Winter 17. And they were, yeah, I think maybe customer number five or something like that for us. I think DoorDash was a little bit before them, but they were pretty early. And the problem they had was they had so many internal tools they needed to go and build,

but not enough time or engineers to go build all of them. And even if they did have the time or engineers, they wanted their engineers focused on building external phishing software because that is what would drive the business forward. The Brex mobile app, for example, is awesome. The Brex website, for example, is awesome. The Brex expense flow, all really great external ph external software. So they wanted their engineers focused on that as opposed to building internal CRUD UIs. And so that's why they came to us. And it was honestly a wonderful

partnership. It has been for seven, eight years now. Today, I think Brex has probably around a thousand Retool apps they use in production, I want to say every week, which is awesome. And their whole business effectively runs now on Retool. And we are so, so privileged to be a part of their journey. And to me, I think what's really cool about all this is that we've managed to allow them to move so fast. So whether it's launching new product lines, whether it's responding to customers faster,

whatever it is, if they need an app for that, they can get an app for it in a day, which is a lot better than, you know, in six months or a year, for example, having to schlep through spreadsheets, et cetera. So I'm really, really proud of our partnership with Brex. Okay, Retool is the best way to build, maintain, and deploy internal software,

seamlessly connect to databases, build with elegant components, and customize with code, accelerate mundane tasks, and free up time for the work We are joined once again by Dan Moore, who we first met because of his awesome blog letters to a new developer what i wish i had known when starting my development career we did that episode with you dan about a year ago now that one's called dear new developer and now you're back welcome back man yeah thanks for having me back. Thanks for coming. Adam's also here. Adam, welcome back. Man, I'm so glad to be back. I love this show. It so asked me

to be part of it, you know, all those things. Recovered from your flu? It's all gone, you know. NAC. Gotta take the NAC. I know what that means. Well, if you're a weirdo, you would know. Dan laughs. You must know what he's referring to. NAC? I don't. I that means. Well, if you're a weirdo, you would know. Dan laughs.

You must know what he's referring to. N-A-C? I don't. I just look at him when I don't know what's going on. That was a pity laugh, Adam. You've missed us both with this. Not another character? I don't know.

What's N-A-C? It's an acronym, obviously, and I cannot pronounce it. So there's a lot of speculation in the medical industry because there's a lot of suppression of like what will actually heal you and what will not actually heal you, you know?

And so NAC is an acronym. I think it stands for, I don't even want to try, honestly, but it replenishes your glutathione. It like zaps a virus pretty quickly. It supports immune health, essentially. Got you you so this is a shot you take is this food is it minerals it's a versions of that it's like it's a pill you know uh similar to like maybe like magnesium might be like in terms of pill form like that size it's pretty big but it zaps a cold. So yeah, now, you know, reduce inflammation, zap your cold,

support your immune health, NAC. Check it out. Awesome. Also pronounced N-acetylcysteine. There you go. You didn't want to try it, but I tried it. I didn't want to try it. Yeah. I was like, nah. Jared's not afraid. Too many letters. I mispronounce things all the time. Not going there. Heck, on our last news episode, I said it was 2024. So I'm not afraid to many letters pronounce things all the time not going there heck on our last news episode i said it was 2024 so i'm not afraid to embarrass myself publicly yeah this is the problem with templates you know you build yourself a template and then you use the template and the template probably supports interpret string interpolation or some sort of logic where you could like have the current year but i don't got time for that. So I just had it say 2024,

and I reused my template and forgot to change one thing. Well, we're back in time. It rolled off the tongue, too. It sounded real good, so I just... I bet it did. You're like, yes, this sounds familiar. Oh, yeah, 2024. Yeah.

Anyways, Dan, you are here to talk auth, so not letters to new developers, but maybe letters for all developers out there. We have a fun conversation teed up and you have some expertise in this area, right? Maybe tell everybody what you do on a day to day what you're up to. I know authentication, authorization, I don't know what's all involved there. But yeah, give us a little bit of your context. Yeah. So I've been for the last about four years, I've been working for an auth provider called FusionAuth and I've done a variety of roles there and spent a lot of time talking to customers about how to implement auth, a lot of educational content. And when I say auth, you know, it's authentication, authorization, and user management. There are some other aspects of the authentication or user lifecycle that we don't really focus on, like identity verification or kind of workforce-oriented stuff. We're much more focused on customer identity access management. So that's my expertise. And that, you know, learned about OAuth and SAML and OIDC and JOTS, you know, basically alphabet soup in terms of jargon,

but yeah, I spent a lot of time decoding that and taking it, rewriting it or rewriting my understanding in such a way that developers would actually be able to apply it kind of in their day-to-day life. Auth is one of those things that is so interesting. We even use it as a base case for like build versus buy decisions, because at its simplest, it's completely a build thing. Like it's a solved problem at its simplest case, right? Totally. But then the thing is, is like there's this sprawling concern that happens over time with it

where just the simple case doesn't isn't sufficient over the course of time and so all these other things come in sso mfa more alphabet soup and now you find yourself kind of reinventing lots of little different wheels in order to stay in in the build camp on that particular thing. And this is back in the developer zeitgeist right now because there's been some conversations around magic links, one-time pass codes or passwords, pass keys. Our password's dead. We got excited about pass keys, Adam, you and I, last year,

speaking with 1Password folks. Is that right? It was. Yes. And didn't actually roll them out for our site, but have been longtime Magic Links users, so I know all the drawbacks of Magic Links. Yeah. I've hit them all.

And I was pretty excited when I implemented them back in 2016 for our website. And we have not that many people signing in and technical users. And so it seemed to make sense. But still have hit all kinds of things that are just little. Sand in the gears, huh? A little bit of little friction. Yeah, just like, oh. Yeah.

You know, and so ultimately we're all trying to either augment or replace password base auth, you know, because of the security concern. It's just like so prevalent. And I actually want to ask you, like back in 2016, was that the main reason, the main impetus for doing magic links was security concerns? Basically, it was like, I can't lose what I don't have. Sure. And I don't have any reason to store your password if I can get away with it. I had realized I had this little epiphany. I think other people were starting to realize this as well, that the forgot password flow

is what most people end up doing when they don't visit a website very often. And our kind of website is the one where you're not going to visit all the time. Like you're going to come in, you know, subscribe, unsubscribe, comment. Once every couple of years, exactly and so every time you come back unless you live in password manager land which admittedly a lot of our people do you're doing the forgot password flow anyways and so what if we just only did the forgot password flow it's just as secure only better because now i don't have to have passwords in my database anywhere ever. And there's just nothing I can lose. And that was basically the reason.

And I still like it for that reason. But yeah, there are all kinds of little, like you said, sands in the gears that you run into with magic links, the most of which for us has been delayed email. It's just like, even if you get the email right away, it's a little bit slower than a password manager. Enough time for people to be distracted, right? And like, like move away, go back to Hacker News or listening to ChangeLog or whatever they're doing before.

And then they forget why they, why was that on this site? Yeah. It breaks the flow. It does break the flow just slightly, but it really breaks the flow if that email isn't delivered immediately and it's delayed two, three, five. Sometimes, you know, if things get circling up there in the ether and not landing 15 minutes, 30 minutes, now you're basically like, I can't sign into your website. We've had that issue over time for sure.

It's interesting because the bigger issue we've seen around magic links actually is corporate link checkers and expiring the links um and we've gone to some pretty um extensive lengths to try to fix that problem um but it's it's kind of the same kind of thing right like you're doing something that's a little bit out of band and you don't have kind of control over that whole experience right whether it takes well for the email to be delivered or the emails being read by something else and expiring a one-time code or something like that. So I actually hit that as well. What do you guys do about that?

We require like a post. So I think we do a JavaScript post of the, so you take, you're taking a page and then the JavaScript on the page executes in posts, which is what actually logs you in. So those link checkers aren't smart enough to do that yet. And so that kind of means that when the user clicks, they're opening a browser and that browser's able to do that post. That's exactly how I handled it as well. I had specifically,

I think Outlook certain versions of Outlook or maybe live 365. It's a Microsoft product. We'll pre-click on links for you in order to do malware checks and blah, blah, blah, blah. And so they would use, just the get request would use that one-time password and then you'd hit it yourself and it wouldn't work anymore because it's been used and i had enough people complain about that over the years i mean we've been it's been nine years so you know we don't have that many outlook users but enough where like i don't want anybody to have a bad experience and so every time i'm like i for a while i was like please don't use crap software no offense that didn't work offense to anybody who uses it but to the software itself it's just not good email software but then i'm like well that you can't you can only say that a couple of times. And then like the sixth, seventh time, I'm like, I got to solve this problem. It can't be that hard. And so it's like, well, I guess I just require a JavaScript. You know, I just changed that to you land on the page and then the page itself does the post and that's what gets you in. And that solved it. But again, one of those

little wrinkles that you don't think about until it's deployed out there and people start to complain. So you expire after a bit then? You expire after the first click? Is that the common case? Well, it's a one-time magic link. And so once it gets used, you don't want it to still work. I mean, you could build in some kind of like slop factor, right? Like let it happen two times or three times, but it is, you know, the entry point into your application. And there's definitely some worries around that. Right. So we, we definitely, ours is still one-time use for sure. That makes sense. But I mean, I think there's an interesting point in kind of what you were saying, Jared, is like

you as the authentication system is kind of unique among, like, sometimes I think of an authentication system, like a database or a queue or something else like that, where it's kind of part of an application and it's foundational, but it's undifferentiated. And then at the same time, it is so user facing, right? So unlike your data, like you can swap out a database behind change log if you wanted to. It sounds like it wouldn't be very much fun, but you could do it without ever affecting the user experience. Whereas changing out your authentication system would definitely impact users. And because it's in the user flow, you really need to meet users where they are, right? Like you said, the first four or five times you're like, hey, can you please use different software? And after a while you're like, well, I really want you to log into my system. Therefore, I need to be the one to change, right? Like you need to adjust to where the users are coming from. Yeah, absolutely. It's just this balance between optimal security and

usability, which is so hard to strike. And because everybody kind of wants to do it their own way. I mean, there's people who are like SSO for life, right? Like, just let me log in with my Google account. I'm actually the opposite. I don't want to use any of that junk. Very much so, yeah. Unless the service specifically connects to a thing. So like, if I'm going to use a piece of software that's going to use my GitHub

accounts information in order to augment my GitHub experience, fine. I'm happy to log in with my GitHub, uh, cal.com, right? I'm going to sign in with my Google account cause that's where our calendar is.

It has to have it anyways. But other than those things, like I just want to enter my email address and add them here the same way. Even so, even with the GitHub, whenever you get to that second stage where it says this is what it's accessing, I feel like that's just such a weird. If you're listening to GitHub, that's a bad page. It's always overwhelming and confusing. And I feel like I have no control over what I can and cannot share. Right.

Just off. It's nice that it's there because you can stop and decide versus it just going through. For sure. But I agree. Like if you could have check boxes that you could uncheck, like, you know? Yeah.

Not granular. Not granular at all. You can see it, but you can't control it. It's overwhelming. All orgs, read, write, like all this access, it feels very thick. Like Tailscale, I use Tailscale, and that uses GitHub for a good reason because I use GitHub as my, I don't know what they call it actually,

what their terminology is, but it's not built on my Google SSO. It's built on a GitHub SSO, so it's built on that auth, and I don't know how to describe it. The whole entire Tailnet is built on my GitHub auth account, essentially. So that makes sense. And giving it access to things might make sense. But at the same time, it's accessing zero repos. It's literally just my network.

It's not GitHub related at all. And it's a little annoying, honestly, because now you have access to something else that, you know, it could be your code. It could be different things that matter to you. And you've forgotten what you've given it access to. And it's like, why murky those waters? Like it's it's my repo places where I do open sources, where I do proprietary code is where these potentially sensitive items could be. You know, it could be accidentally committing an API key.

And then now I'm, you know, that's terrible. Don't do that. But then also like whatever else I've connected to my GitHub account might somehow be able to access it too, if there's a flaw in the system. So Adam, sorry, like I haven't used tail scale myself personally. I've read about it, but like, is it when it, when you're logging with GitHub, it's prompting you for a bunch of different permissions. It's not just saying, Hey, I just want his email address.

Let me log out and see what happens, what it actually accesses because I just personally find that screen a little overwhelming every time I see it. I'm like, okay, this is a lot of stuff. Okay. So now I'm actually on this page that says authorized Tailscale. Yep. And at the very top, it says Tailscale by Tailscale. This wants to access your Atomstack account.

Its existing access is read org and team membership and read org projects. So I'm like, okay, why do you need to have, if you just want to auth me to Tailscale, why do you need to list my team memberships, my org projects? Why do you even need to know anything about my GitHub database, basically? So honestly, I wouldn't blame GitHub for that. That's actually on Tailscale because Tailscale asks for permissions. All right, Tailscale, fix this.

Yeah, yeah, Tailscale, come on, man. Come on. You don't need all that. Access user email addresses read-only. So if I have multiple email addresses in my GitHub account, it's like, well, okay, maybe. And then organization access. And it checks every single org. Every single org.

And I can't uncheck it. So my feedback on that is... That is a GitHub thing, though. That's a flow. Like, that's common for everything. It's not just TaylorSkill. It's every time I go to some sort of GitHub auth, it's giving me organizational access that i can't revoke and all i want to do is off well and so my guess is that there's it's probably you're right

it's probably a combination like i haven't delved deeply it might be the github api too you know that's just how it works it's like yeah how coarse grain does github allow permissions to be asked for and then what permissions is tailscale asking for and my guess is this happened like this is probably a little bit like the magic link experience that Jared was talking about, where started out and Tailscale asked for like very small amounts of data. And then there was a use case and then they need to ask for a little bit more. And there was another use case and they need to ask for a little bit more. And then they can't differentiate between whether you're doing the simple use case where all they need is the email and password or not your password sorry just your email or the complicated one that's my guess on what happened um based on kind of what i've seen

over over the years is best of intentions but github having coarse grain permissions makes it really tough to like ask for just what they need right and sometimes the other strategy i can i can rationalize the other strategy which is like i don't know let's just ask for as much as we we might need it eventually anyways just ask for more and that way we don't have to come back and like re-ask later if we decide we need this thing and so especially certain people who are like data miners like we may need you know the thing about just collect all the data we may need it in the. It's easy to sell that in a meeting, I think. Totally.

For sure. Ask for more than you need. Come back later. Never. Right. I always felt like GitHub Auth was, it felt, anything I authorized with GitHub, it always felt like whatever was being asked of the authorization process was more than I thought was necessary in the authorization process.

In almost every case. And Adam, your reason of disliking it is actually, I guess, deeper than mine. I'm a simpleton. Mine was just like, I don't want to have to go to every website and think, which provider did I create an account with? Because you end up with like two accounts on different places because you try this, then you try your email and you're like, oh. And so it's like, if I just use email everywhere, then I then i never have this problem again exactly that's my basic premise is that but tail scale

requires you to use an auth provider or some sort of sso because it hinges your tail net upon that username and how you authenticated so in that case that's where i had to so i'm by force of sso with github or like you had said with cow.com for example like that totally makes sense I'm cool with it there in almost every case my default is I'm gonna email authenticate and password authenticate by default because that's what makes the most sense to me as a user because I don't want to ever think, like, how did I off to this? And then I go back to the thing and I'm like, I think this actually happened with Neon when we first set up Neon.

Their original flow, I believe, only had SSO. And then when I went back again, it had email. I'm like, okay, my default is email because that's how I do it. And I couldn't log in. I'm like, well, what happened to my Neon account here? I'm like, okay, now I because that's how i do it and i couldn't log in i'm like well what happened to my neon account here i'm like okay now i can't get in oh yeah i must have off with github because that's how it originally was you know six months ago when they first rolled off but i'm with you you know i think that uh you ask for too much the flow is weird i prefer just to know my email if it's a work account it's a work email if

it's personal it's a personal email and i keep those words very there's a lot of people who have one email inbox for all their life and i'm like how do you do that how do you you know i may not be an inbox zero guy but i'm a definitely a segregated and separated inbox based upon you know disciplines in life or categories in life right i separate the accounts but i do read all the emails together so i'm kind of on the fence there but i'm also inbox zero so they're relatively taken care of unless i'm actually behind dan what is your opinion on people saying, well, just knock it off with all this fancy magic links, one-time passcodes, like just email password, like forget the SSOs. If we all just did email password, like the old days, life would be better. What's your opinion on that?

I would love if we would do that if everyone was using a password manager. And I think, you know, depending on your audience, that could be a viable path. But for a lot of customer-facing organizations, you know, or applications, that's just not reality, right? Like my wife is a relatively smart person, has more degrees than I do, is not super technical and gets super frustrated with your password manager.

And I have one that I've been using for years that I love that is fantastic, but I would never wish it on anybody else because it's kind of, it's old school. Right. So really, uh, it's called a password safe. mark schna uh not i think

who's the schneier guy bruce schneier recommends it and um it's open source and just kind of super dumb but um it's not like integrated with any external systems because that's the other worry that i have with password managers like oneword or LastPass we've seen is they are super valuable targets, right? Because they have everything. I think you should always offer username and password as an option because I think you're going to have some subset of people who are going to be more comfortable with that, but I don't think that it should be the only solution. I feel like it's the email of the internet insofar as that good luck erasing the protocol email from just the way humans do internet totally i say humans because we now have non-humans doing internet we're also

good at email yeah they're getting better at email so you're saying passwords not just they aren't going anywhere but you think they shouldn't go anywhere. I mean, here's the nice thing about a password, right? Like the, the strengths of the password and the weaknesses of the password are very similar. One is that it is something that can be shared really easily, right? And that can be shared with family or friends, or it can also be shared, you know, or discovered by an attacker. I think you need to, as someone holding passwords, any of the systems, you need to make sure you take care of passwords. You need to make sure that you hash them appropriately.

You make them hard enough to use for an attacker that you can avoid credential stuffing attacks, but easy enough for users to use. And I think the reason is that it's lowest common denominator, right? Like I have definitely liked Tailscale, Adam, but this was a different company that all they offered was social login. And that is frustrating to a certain class of people, to a certain set of people who don't want to necessarily tie things to third

party providers, or maybe they don't want you to know that their particular email, they want to use a username, right? You can't use magic links with username-based solutions. And for certain kind of sets of folks, right? Or even classes of applications like games are a perfect example. Like games don't need to know your real identity. That's a dumb thing. So I don't need to know your real identity that's a that's a dumb thing

so i don't think they're going away i think that there are great solutions that you should offer and each solution you offer kind of increases your marginal kind of market size of people who are willing to kind of log in and that includes what we talked about magic links we talked about social login um i think we're going to talk a little bit about passkeys. And it's a yes and rather than a, you know, we're going to move entirely from this solution to that solution. It certainly bolsters the, I would say, the new trend over the last, I don't know. Is it new if it's past five years? I don't think so, it's it's newer okay

i would say over the last five years you got like work os you've got um obviously fusion off you've got off zero and i'm sure there's like at least one other major major brand that i'm totally forgetting right now dan probably knows oh i can give you a list right like i mean key cloak clerk zitadel ori i mean there's uh propel off there's a there's a ton of I can give you a list, right? Like, I mean, Key Cloak, Clerk, Zitadel, Ori. I mean, there's Propel Auth. There's a ton of people out there doing that. Totally. So there's not a cottage industry of startups that are well-funded, probably even well-ARR'd and doing well.

Well, even the IPO didn't offer zero or October zero. October zero for six and a half billion dollars so like that's past the startup phase and like 20 it was like 20x their arr right yeah so yeah i mean from from startup to scaled up yes yeah point is is that now it's so complex to do off that we now need to off load it to a paid service in order to even get it right. Or to avoid from having our developers waste time building something that's been built and can be serviceable or turn into a service. And then it makes more sense to buy it versus build it. And mainly it's not because they couldn't build it.

It's like, why would you build it? And then the ongoing security concerns around Auth now get offloaded, handled by a third party, hopefully, in quotes, trusted, or well-trusted. And now we've got different places you can

get attacked. Thankfully those players have done pretty well. I don't know. It just seems like now we've got such a complicated situation. You also end up in the same situation with 1Password and LastPass when these providers become huge targets. Of course they probably have their security teams staffed up because if I can hack into Okta or FusionAuth or whatever it's not just one company's stuff I'm going to get.

It's like a smorgasbord. Well, so I want to, actually I want to push back on that a little bit because, and this is one of our kind of unique selling propositions, which is the only reason I interrupt Adam, is that with FusionAuth, you're actually getting dedicated database

and compute resources. So it's totally separate. It's not a multi-tenant solution inside there. How separate is it? Like different locations? It depends, but we can deploy to any of the AWS regions and you can run it yourself too, right? So you can run it in your own data center.

But the idea there is that, you know, if you escape a competitor who has a multi-tenant SaaS, depending on their security posture, you may be able to kind of access other users' systems, but you can't inside Fusion Auth because it's like separated. It's a separate database. But I do want to talk... I mean, Adam was talking about the complexity of it. To me, it feels like the evolution, it's the same evolution as email, right? It used to be, you were sending emails, you'd stand up like post fix or I don't even remember those, you know,

send mail. And then SendGrid came along and other mail providers came along and email deliverability became a more complex issue. And so it became something that was outsourceable. And a lot of people have made a lot of money doing that. And a lot of apps have been built on top of it and it's a trade-off, right? And if you are, you know, super bare bones and you're a Linux gearhead and you know how to set up send mail, you can still get by by doing that. But the vast majority of the world has changed. And people have just acknowledged that it's not worth it. And I think auth is kind of undergoing that transition too. So I agree with that comparison, Dan, I having done both, I can tell you that rolling your own auth is considerably easier than operating a post

fix server and with spamin and these other things on the public internet. Also, there's a step in between. You know, you have, I build my own auth system with my own first party code, and then you have auth providers on the other side. And in the middle, you have open source solutions, which many frameworks tackle this head on because it's hugely valuable and can't have pooled resources there. So there's a nice middle ground with auth, whereas with email, you're kind of doing it yourself or doing it with somebody else's. Fair enough. Well, friends, you can now build invincible application thanks to Temporal, today's sponsor.

You can manage failures, network outages, flaky endpoints, long running processes, and so much more, ensuring your workflows and your applications never fail. Temporal allows you to build business logic, not plumbing. They deliver durable execution and abstracts away the complexity of building scalable distributed systems and lets you focus on what matters, delivering reliable systems that are faster. An example of this is Masari. They are the Bloomberg for crypto. They provide market intelligence products to help investors navigate digital assets. And they recently turned to Temporal to help them improve the reliability of their data ingestion pipeline.

And this pipeline collects massive amounts of data from various sources. And then they enrich it with AI. This process previously relied heavily on cron jobs and background jobs and queues, and the design worked well. However, these jobs were difficult to debug at scale because they needed more controls and more observability. And as they looked to rethink this ingestion flow, they wanted to avoid cron jobs, background jobs, queues. They didn't want to create a custom orchestration system to oversee and to ensure these jobs and work was being done reliably.

Here's a quote. Before Temporal, we had to code for dead letter queues, circuit breakers, etc. to ensure we were resilient to potential system failures. Now we eliminate these complexities. The headache of maintaining custom retry logic has vanished by using Temporal, end quote. So if you're ready to build invincible applications and you're ready to learn why companies like Netflix, DoorDash, and Stripe trust Temporal as their secure and scalable way to build and innovate, go to Temporal.io. Once again, Temporal.io. You can try their cloud for free or get started with open source. Once again, Temporal.io. Once again, Temporal.io. You can try their cloud for free or get started with open source. Once again, Temporal.io. So let's go back to Magic Links and talk about OTP because this is kind of, to me, seems like maybe an evolution of Magic Links and an improvement. So the idea here is, is that I'm still going to send you

something that you can then confirm that you have, but instead of just making it a link, which in our case, it's like a long, it's not like an MD five, some, but it's, it's, you know, it's like a hash value that you would not be able to just rattle off. It's shorter and time-based and usually it's six numbers that are provided. And so the, the one-time passcode is sent to the email or whatever way you can send them. So you can push notify it or whatever. And there's a click provided. So you can still just click on it and just embed it in the URL in that case, or you can just read these six characters and type it back out and that really solves one particular bummer about magic links is the shareability aspect and the like switching context aspect which a lot of people run into is like hey i'm on my phone i send myself a magic

link and i don't have that email app on my phone or there's like all these different weird things where it opens in a app specific browser inside of my email client and so it logs me in inside of gmail app but I go back to my other app and I'm not signed in well with these one-time passcodes you know you can solve that by just either copy pasting the the six digits or just remembering them for 10 seconds and typing them on the other side. So that seems like a nice evolution. It's like a constantly rotated password, really, right?

Like the OTP is constantly like, it's like you set the password every single time and you email it to them and it's time-based. So it's like, that is a cool method. I prefer, I like that method. It doesn't bother me. You still have the trappings of it getting to them in an abnormal way versus stored there in their password manager or remembered in their brain.

They have to fetch it every single time. But at least you're not stuck to it has to be a link. And if you're dyslexic, like I am sometimes, I read it backwards. I will misremember. I will literally read it and have to say 1-6-0-5-8-0, like whatever. And I feel like that's also an attack vector because maybe somebody is sitting next to me and I'm like lightly whispering this password that is only on my screen. 1-6-0-5-8-0.

I don't know. I always feel concerned about that. If if i'm alone it's just my pup with me my dog then i'm cool with it right but if i'm at starbucks or coffee shop then you could be you could be trying to get me yeah it's a good i mean otps are a great solution for sure i mean they they still share some of the issue with magic links right like in terms of the deliverability um like time frame and a little bit of discontinuity there but um they definitely step around a lot of the the other complexities yeah whether it's about like browser-based stuff or the link checkers or whatnot yeah absolutely so you still run into that stuff pass keys however uh you do not have to send a pass key to somebody

every time they have to sign in because it's a pass and hold, right? You get the passkey, you hold the passkey, and as long as you have the passkey, you're good to go. In fact, they are integrated to a certain extent inside of autofills on phones, whether you're on Android or iOS, if you're using the right first-party passkey stuff. I'm not sure we're going to get into that because this is where passkeys get weird is like who's got the passkey um but as long as it's in there like on ios for

instance if it's stored inside your apple passwords app it will autofill or face id or touch id just like your password would and so it's instant once you have it there, but it's also complicated. It's more complicated than that, isn't it, Dan? Yeah. I mean, there's definitely, there's a couple of kind of things to think about with pass keys. Um, one is like how you set them up. First of all, um, kind of the, the registration process is a little bit weird and can kind of differ. And depending on the pass key, it might be tied to a physical device. It might be tied to an account. You know, if you're worried about people correlating things across like OAuth or OIDC, you know, the same thing is happening with passkeys that are shared. Or if it's device specific, then now you're kind of tied to the device. And then kind of, I think the user experience is, for actually logging in, is pretty good.

It does, you don't have as much control as the thing that you're logging into, the app you're logging into, doesn't have as much control over like the look and feel or the messaging or anything like that. And that can be problematic too. But the beautiful things about pass keys are they are locked down in two ways, right? They're locked down to the device or the system that holds the private key that is actually kind of generating the challenge and like solving the,

basically, I can walk through kind of how pass keys work if that'd be helpful. But anyway, there is a work if that'd be helpful. But anyway, there is a private key that is held someplace and that is what's used to kind of authenticate you. And they're also locked down to the domain, right? They're associated to a domain,

which is really, really great too, because it removes all kinds of phishing problems, right? Like, because you're trusting the computer to recognize the domain rather than the user looking at the UX or looking at the URL bar. And computers are much better at comparing,

you know, character by character and making sure that things are all correct. So there's two kind of security benefits for passkeys, for sure. And yet people don't seem to like them for some reason. So I have had nothing but positive experience with passkeys as an end user and i should say that my my stack is basically apple stack i want an ios and mac os and i use the passwords it's now its own app it used to be

keychain and inside the settings of the iOS stuff, but it will handle both your passwords and your pass keys for your domains. And it will even allow you now, I think this is new, last year to share those with your family, which has been, in my experience, seamless as well. I can share a pass word. I can share a pass key. I can create little subgroups in my family, like just my wife and I, or my kids and us, and I can share them there. And I have to say, I've been just tickled with how well that's gone. But I think I'm very rare in this, because a lot of people are just not happy with the way things are going. And Adam, you're not sold on pass keys. So what's been your experience? Yeah, did you see my title change change not yeah that's why i said it's not your title is not sold on

passkey so i knew you i think it's mainly it's less about the protocol and what the attempt is it's more the seemingly rogue implementation every single time I experience a passkey scenario. I also find that services are defaulting to passkeys and it like bothers me. When I want to be a email password person, it's constantly just slapping me in the face like, where's your passkey? And I'm like, nah man, I'm doing email and password, okay? And it just seems like I always want to default to this thing. Adobe does it. I sign into the document cloud a lot for different agreements and stuff like that. So I'm in there doing stuff frequently.

And I like to log into the actual online service. And so I'm logging into Adobe's web services frequently, and that's their flow and I'm cool with paskies I actually like them except for I think the flow and the way the UX is still implemented seems to be just not the same across the board whereas email password is pretty much the same across the board I feel like that's the holdback for me and whenever I don't want to be password first, or sorry, passkey first, that I want to do email password or just anything else, that service is sort of like force-feeding me passkeys.

And I'm like, you know, nah, man, email password, okay? Now, I do use 1Password, though, to just identify my stack. So unlike Jared, Apple, simple, free, with it kind of thing. And I don't think that's not his only reason for using it. I know Jared well enough. He likes to keep his stack simple. He doesn't have to have other extra services if he doesn't want to kind of thing. And I think that's cool.

That's how they use it. That's cool. I use 1Password for a lot more than passwords. I've got secure notes in there. I've got like, I mean, I don't want to tell everybody what is my attack vector. It's a lot, okay? Sure, sure. It would be really bad.

It would be really bad if 1Password was not a good long-term security solution and they were attacked on my behalf. I use it for more than passwords. So Adam, I'd love to probe that a little bit more because to me, you know, some of this just may be because growing pains of past case, right? Like usernames and passwords have been around for a long, long time. Yeah. And even now there's still, you know, some wrinkles like sometimes people will ask for your username first, right? And that's so they can direct you to the right identity provider

if you're, you know, whatnot. But like Passkeys, it feels like it, you know, they were just codified in like 2019, right? And so that is not new, but it's still being kind of rolled out. So you think some of us just can get shaken out in terms of like the right UX or? I sure hope so.

Like I'm long on what it can offer, but I think that, some of it's just going to get shaken out in terms of like the right ux or i sure hope so like i'm i'm i'm long on what it can offer but i think that let me try to define some of the other user flows that have bugged me and i'm i think i'm a pretty patient user because i get it i'm in this space i'm not your typical user where i understand where the technology is going i understand the benefits of passkeys i understand the implementation for the most part. And so I get it. But what ends up happening is, is because it's potentially a newer, potentially more secure way to authenticate with a service, they're injecting it where normally it would just be email password. And I would not have any other interruptions in my flows with authenticating. And so now it's like, well,

after I've authenticated with username and password,'re like hey do you want to store paskey no i just want to go through the door and shop i want to get what i came here for right exactly yeah don't ask me do i and don't be secretive about it and and say do you want to authorize next time with your fingerprint or your face ID? Like they hide it or they masquerade it as this not pass keys. To me, that's not masquerading. That's actually promoting it in a way that's of a benefit to you. Because don't you want to, wouldn't you rather just face ID in than your name and password?

I don't think so. No, I'm explicit. It's back to that potentially with, and maybe this is where my psychology is with this or the way I'm thinking of it is, is because I don't want to think about how did I authenticate with the service. And maybe next time it's just so automated because the way one password works, this way and you got to keep it the one way versus like sprinkle your sso's around and then also your potential email and passwords so i'm like nah you know i'll just keep it the way i want to keep it and stop bothering me about paskies i will say to caveat all this is just to give fodder for a conversation because I truly am enjoying it insofar as that I've enabled Passkey's usage on my Adobe login. The flow is kind of weird though, because I will authenticate with the Passkey, but there's not a good feedback loop. You can't see a spinner. You have to know

it's going to authenticate because if you click that, you basically wait two and a half seconds. In my case, it's about two and a half seconds. Then I'm in. It's not a lot of user experience visually to say the passkey is being exchanged. Something's happening here. And so I do authenticate that way. And it is pretty magical that I just click one link or just one interaction essentially and I'm in. But it's about three-h seconds later roughly i didn't

want to say like i don't think it's just for security that's the that's not the only reason that that um new orgs or or that passcodes are getting kind of pushed i think it's also a user like they've done studies that it just gets you into the app faster um there was something i'll share the length but this person referenced a Microsoft study that said that the average time to log in went from 69 seconds with using a password slash MFA to eight seconds with pass keys. And so if you can get someone into Adobe quicker, especially someone who doesn't have your depth of experience, Adam, and doesn't really understand the big thing.

And they just want to get to Adobe and you can decrease it by 10x. That's a big win for everybody. I don't know. I feel like my email password logins have been pretty fast. I will say that 2FA, MFA scenarios slow it down a little bit. Adding that into, so one thing I like about 1Password is that it allows you to 2FA, OTP, MFA inside of your 1Password. So you can actually let 1Password do that coding, I suppose,

like getting those codes back and forth. And it automates it in its autofill process too, so it's pretty quick to my knowledge. There's times when it's slower. The other cool thing I like about that flow, not that it's better than Passkey's, I feel like you're going to always have every way to log in. That's why I feel like Fusion Off has such a long game here

because you're never not going to have one of these other scenarios. There probably isn't a silver bullet because you always have all the ways, you know, essentially. But if you have a shared 1Password record, let's just say. So if you have a multi-user 1Password org or an account and you have a password or an authentication that's shared with somebody else, it could be to a shared email even too. So email password is now shared between two users, but that 2FA MFA OTP code that gets manifest on a cycle is inside of 1Password and accessible to all the users of 1Password. This is probably the same with Bitwarden and others too. I'm sure it's a common user experience. But the cool thing is, is that even with that multi-factor authentication scenario, you have this shared truth, this

shared source of truth that allows you to authenticate even with these other security measures like OTPs, 2FA, MFA. I will say that I totally understand the user experience benefits of that. It scares the crap out of me right because the whole point of mfa is that you have you have a separate like and and my guess is one password kind of segregates that stuff inside their own system right so that an attacker coming in getting access to the passwords would have a hard time getting access to the the totps i have a really hard time getting access to my own onePassword. To add 1Password onto a new device, it's not itself like the password itself can be very long it can obviously be if you're on a new m mac kind of thing you do your touch uh touch id into which i love i mean i think just touch id authentication one password to me is like the way i mean every

linux user bow down to the way it's just now. I mean, like maybe you could do that on windows and Linux, but I just experienced it again today. And I'm like, this is the way. Okay. Everyone else has just like lost in comparison to Mac OS's abilities to do this again, just to push on this a little bit.

It doesn't worry you at all that like this thing that is supposed to be a separate factor is all wrapped up in one place. Let's see. How worried am I on this? you want to do a scale of one to ten well and obviously depends on your account right like they're probably accounts that you don't care about right like but let's say your bank account like how much is that worry you on a scale where 10 is like i better go change this right now my hair's on fire and zero is like eh you know i don't really i trust everything's fine well okay um now that you said this thank you very much i i guess my my concern is elevated and i think it goes back to the level of trust that i give to one password or whatever supplants it in the future

if that's ever a case. I think it concerns me in this conversation that it's true that I have a large footprint, a large attack vector in one service. That being said, I've had many conversations with the people behind 1Password, and even a trusted security professional that's a close friend of ours, love their protocols. I'm speaking of Firas, Jared, back in the day when he was doing wormhole and all that stuff, he was really praising their security measures. That being said, obviously anything is attackable and you can get past it. So I think I put a lot of faith in 1Password security measures, really.

And I just hope that in the future my bet on that security measure remains valid and true. And if they ever get attacked ad nauseum, I guess I'm just screwed. I don't know. I guess at that point I'm not that worried about it, honestly.

Five, maybe. Five. And I just want to disclaimer, I don't know anything about 1Password, right? Like, I'm not, like, attacking them in general. It's, like, the general principle of, like, MFA. I think we should. I think they should be scrutinized. I think we should hold them.

No, I do. I really do. And I think they actually, I think they welcome it. Because, like, if you're in security and you are that kind of attack vector, you should 100% desire scrutiny. Not because you're scrutinizable, because you should be. You're a security place with so much wealth of knowledge on people. You should be scrutinized, and they should welcome it, in my opinion. Well, I'm wondering what a good multi-factor auth segregation would look like in terms of you're trying to sign into your bank.

You're on your phone. What could your bank do that would be better than having a password and an OTP code in a singular password manager? Would it be multiple password managers? What would that look like? Yeah. I mean, I think that it does depend. I actually wrote a blog post about this, about the different kinds of MFA for customers, right? Again, employees are different world because you can force them to do all kinds of

stuff and you can spend money on it. Carry this YubiKey around. Totally. Totally. But for customers, you know, I think the, an important thing is that it is going to at least a different piece of

software, right? So, you know, using them in passwords, being pulled from password manager, and then using a different software authenticator app like Google Authenticator, Authy. There's some open source ones out there.

You know, even sending SMS. Like I know SMS is problematic in some ways because it's attackable in certain circumstances for high-value accounts, but it's still landing in a different place on the phone. Email address, one thing that I think I wish everybody who allowed email as MFA would do is have the multiple email addresses and have those email addresses not be tied to the email address you use to log in. Right. So I could set up, you know, Dan at Fusion.io is my login identifier. Then Dan at example.com is my MFA. And again, you're just separating things out and you're not, you know, every step you take to do this makes things just a little bit harder for attackers. Right. And so that's the whole goal is, you know, it's not to, if there's a

state level attacker out there, hi, anyone who's listening from a state level, you know, actor, like they can probably get access to my accounts because they have those resources, but I'm just trying to make it difficult enough that they kind of, um, that normal attackers move on. Yeah. That makes total sense. I think having multiple pieces of software, but unless you are an employer, that's really on the end user, isn't it? Like if you're a bank, I guess if you do SMS, you're kind of forcing them into their SMS app or something like that. Whereas with a passkey, I mean, really that might be a downfall of a password plus passkey MFA, because now they both are going to be stored in the exact same place. Whereas, and if you have your OTP codes in there, like, how could you as the bank,

not with employees, but with end users, kind of guarantee them the best chance of having that segregation? Would it be SMS, which is, like like you said kind of has some problems with security i mean i i assume sms or email right like anything that's deliverable is probably going to be outside of your app um you know you could there's always this right we talked about the tension around the friction around like login method and that same thing is true with mfa right and so there's always a tension between making things as easy for adam to log in right as possible or adam to be honest with you like taking control of his own destiny and using tools out there like one password or orbit wardner etc so yeah so you definitely can help foster things by using deliverable methods. That's really the only way you can force that. And honestly, I don't know if 1Password has this or anybody else has this, but it wouldn't surprise me if there was a Gmail plugin that would go and look in your Gmail and pull out the code, right? That Adam could probably install as an extension to one password.

And then he's just kind of circumvented that whole thing again. Right. So, um, and he's the one, by the way, paying the bank, right? He's the bank's customer. So you can't push them too far, but you can, I mean, education is kind of the canonical answer, you know, answer to this is like you say, we really suggest that you take these steps to secure your accounts. And if someone wants to ignore all the pieces of advice and they're still paying you money, that's a really hard question to solve. Yeah.

You can enforce it with like weird passwords, length, which i think is always good and bad i've experienced where i'm like okay for example my uh my trigger smoker i can put it on my wi-fi and there's an app that lets me control it from far away well apparently um it can't do a wi-fi password that's longer than 30 characters and so obviously my my wi-Fi password is probably like at least 32. I think it might be 64, honestly. It's kind of crazy. I don't give it out. It's, you know, it's, I will hand type and my wife hates it.

It's not 64 characters, but it's probably 32. And it's a mess. I'm not saying it's the best solution ever, but my trigger will not do it. So it enforces this limit there. That's not actually a password. It's like acceptance of a password. But there's other scenarios where you try to, you know, redo your password or something like that.

And then when you go to that flow, it yells at you. Oh, not only did you not have this special character and the uppercase and the lowercase and whatever, you know, you've got to meet these criteria. And some of them are just like, wow, they don't tell you like the UX of that flow is like kind of strange. Right. Until you're done. And they're like,

no, that one doesn't work. I mean, NIST actually recommend that they have the latest digital identity guidelines and they actually recommend that you don't enforce that complexity because it's frustrating to end users and they end up picking something that may not be that complex right like they'll just add like the one exclamation point at the end of a normal word or something like that yeah um so i think minimum

length is pretty much the only constraint you should have like it can't be less than eight or whatever it is and then anything else like as long as you want as crazy as you want but like we have to have a minimum amount and don't check the corpus right like there's there's a bunch of corpuses of right passwords out there and check that it's not in there and other than that i'd say yeah go crazy what's up friends i'm gonna give you a peep behind the scenes here we love notion Notion here at ChangeLaw. We use it so extensively. We do a lot of stuff externally from our internal core team and we have to organize a lot of stuff, a lot of workflows, a lot of statuses, a lot of writing, a lot of informing. And Notion is just so infinitely flexible for us. I'm creating workflows, standard operating procedures basically. And it's just such a cool thing to build a workflow, a way of doing things inside of Notion.

And now they have Notion AI and it's saving us so much time. I'm writing with it. I'm finding things with it. I'm summarizing things with it. I don't have to kind of think, where is this in my massive Notion workspace or many team spaces that we have? I just Notion AI it and it comes up. It's so cool. And if you're uninitiated, you may know Notion. I'm pretty sure you know Notion. But they combine docs, notes, projects, all into a single space that you can design yourself. And it's beautifully designed. Mobile, desktop, the web, shareable on the web. It's just so powerful. It is your one place for your team to connect with your tools, your knowledge, and you're

empowered to do your most meaningful work. And unlike other tools out there that make you bounce from one thing to the next to the next, Notion is seamlessly integrated, infinitely flexible, and it's beautiful and easy to use. So Notion AI helps us work faster. We're writing better, thinking bigger. is seamlessly integrated, infinitely flexible, and it's beautiful and easy to use. So Notion AI helps us work faster, we're writing better, thinking bigger, we're doing tasks that normally take hours, and we're doing those things in minutes,

sometimes even seconds. And yes, we're not a Fortune 500 company, but Notion is used by over half of Fortune 500 companies, and teams that use Notion, like us, send less emails, they cancel more meetings, they save time searching for their work, and they reduce their spending on tools, which helps everyone stay on the same page. So try Notion for free today

when you go to notion.com slash changelog. That's all lowercase letters, notion.com slash changelog, and try the powerful, easy to use Notion AI today. And when you use our link, of course, you are supporting this podcast, which you love. And we love that, too. So Notion.com slash changelog. So here's a I'm not sure this is a hot take, but I would say this is a take. Let's just say this is a lukewarm take i feel like password managers or some sort of password management and maybe apple solved this to some degree

is the new ssl in the fact that we had let's encrypt happen more than a decade ago and now a large part of the internet is now encrypted, right? Because of all their efforts with Let's Encrypt. I feel like passwords are so crucial and there's only so many more users of software and you go and find any given person that is just accessing web services in normal humanity, just normal life. 50, 100 services or more, right?

Like it's just so many. And the fact that I'm surprised that 1Password doesn't have a free tier because you would think that would be a phenomenal attractor and the fact that like Apple has already done it in replicating most of the goodness of password management, not so much other things like identity and SSH keys you can put in 1Password, lots of cool stuff. But I feel like password managers or password management is the new SSL in the fact that

we just have to have the best, everybody uses it, free-ish way or a freely accessible way to so many people because there's so many people who just like literally write down their passwords or have the same exact password across every possible service ever and i won't name any names because i know a few i'm torn i want that world i want that world i'm not sure we're there because um the let's encrypt the big lever lever there was Chrome, right? And like the scary warning messages in the URL bar and things like that. And I don't know if we have, I mean, maybe you have that with the operating system vendors. So maybe that's the lever, but it feels like we're not there yet, but yeah,

I would love a place. I love a world. I mean, and honestly, this is, it's interesting to me because the more we talk about this conversation, like password managers and pass keys are both kind of two sides of the same coin, or they're two approaches to the same problem that both believe that computers are better than people at keeping track of, you know, verifiers of identity. And PASCIs do it in a way that's a little bit more opaque and not maybe as compatible, but is a little bit stronger, right? Because it's private public key encryption. Whereas password managers are more like designed to like fit in with the world we currently live in and have all these nice add-ons that you mentioned, Adam.

But I just don't sit well over there. The basics, man. Just password management. It would be great. Doesn't have to be the OTP, 2FA kind of integration. Just let the world have access to – maybe I don't even agree with this. Like email password login is probably not going to go anywhere except for on change.com. Like you're going to like it's still there in a way like you still have email in the flow.

You've got this magic link flow. And so I don't ever concern myself with with change. Log in for myself with that because I don't need to store it. There's nothing to store. But insofar that so many services out there never get rid of it, just having basic email password, secure ways to not have the same password across all the different ways,

I feel like the world needs a version of that. And it's totally, maybe to Apple's credit, it's an operating system level potentially concern or leadership concern in the fact that they've done seemingly the impossible which is give it to

I mean that's free right Jared you're not paying for that well that's all I'm going to say because I feel like between iOS and Android I feel like that's kind of a solved problem right because Android has a built in password manager and I'm sure that's kind of a solved problem, right? Because Android has a built-in password manager, and I'm sure

there's places you can go to to get better ones. And iOS is built-in password management, and like has been there for a couple years now. I don't know what Windows does, because I haven't used Windows in this new millennia, but I assume they got password management built

into Windows, don't they let's google that real quick while you guys uh i don't believe there's a free one in windows what i can tell you is the user experience dan are you a windows user not currently i was until a couple years ago took a couple years ago so i recently uh installed windows 11 as an example so i've been exploring behind the scenes this idea of a creator PC. I like to build machines, but then the operating system I'm going to put on there and do all this work is Windows. And that's just like the sadness of my life. I would never want to do that. And I know that because I literally went down the road. I'm like, hey, it's been a decade or more since I've even

played with Windows aside from somebody saying, hey, you're in IT. Can you help me with this problem? I'm like, sure. I'll look at your Windows. I have no idea what I'm even clicking on here. I love it. And I install Windows, and I'm just so sad for Microsoft that they can't get that right. They have the largest installable base of a computer user on the planet and that's

their best effort it's just i'm just sad for them that's just it's a mess they installed so many softwares that just not necessary and it's just disgusting maybe it's their fault maybe it's not their fault i feel like they can solve the problem they're not solving the problem but you know they're not i don't believe there's a default free password manager in Windows. I Googled it. PCMag disagrees. They say that there's other ones. So they haven't selected like this default installed for Windows.

But, you know, somebody's got to do this. And who's going to leave that effort? It can't be 1Password because they're a service. They're a software company trying to make money i mean i think giving away one password for free is not very smart although it could be you know the xerox of one password or i guess the xerox of password managers is that they could give it away for free to everybody to a certain limit and attract a lot of people and they're already on all the platforms. So maybe that's a good way for them,

but there is no let's encrypt for password managers out there where it's just free to everyone and accessible. I would also say, like, I think that you kind of hit, or you alluded to one of the issues with this, even if it gets installed in Apple, in Apple's operating systems and it's installed in Microsoft operating systems and

installed in Android. Like you still have some people who use an iPhone and have to use a Windows PC, right? And so you have this cross operating system solution that, you know, Chrome, again, the big lever that moved Let's Encrypt, that was cross-platform and it had significant market share. Maybe there's some kind of consortium who could help with that. I don't know. Again, I'd love to live in that world. There's an article from The Verge in 2020 about Microsoft's new password manager

that works across Edge, Chrome, and mobile devices called Microsoft Authenticator. And so this was coming out then. This is an app that you would install on your iOS or Android device, and you would cross that chasm basically syncing with your Windows-based Edge browser. I think it's actually not Windows-level password management. I think it's inside of Edge, which seems like a weird silo. And that could be wrong.

That could be outdated. But there are people obviously trying to tackle that particular cross-platform thing, at least from the Microsoft side. I don't think Apple has any interest in tackling that, as they've historically had no interest in those kind of things, which is a shame. And obviously, and Google with Chrome, I don't know. I think that there are options for everybody, and I think that there are probably free options for everybody. It's different than Let's Encrypt because it's more of an end user concern than it is a server operator concern, right? Like all of us nerds got our free certs and upgraded our stuff to HTTPS. And they made that palatable and free.

And they made the case for why you should do it. And that worked but when we talk about end users around the world varying levels of technical expertise it's just a much taller order but i do think that apple and android have not solved it but provided something a baseline for a lot of people. I mean, if you want to call Microsoft Authenticator, I'm looking at it. Baseline. It is a line beneath the base. You know, like it's

I don't think that, I mean, given their prowess on the compute platform across the globe, Apple is the best effort, and I would not consider that an effort. I don't think Microsoft is investing in Windows like they used to. I think they're investing in Azure and Cloud and AI

and all these other things that have up and to the right opportunities. And Windows is just kind of like last millennia's thing. It's just there. I don't know how they get away with that. Large installed base. What are you going to do? You wrote an app. You have, like, an old app that you're not going to rewrite.

Entrenched. Yeah. Yeah. Well, you got, so you have these services like Azure, and then those services have what? Users. What are those users running? iOS or Android?

I think a lot of them are running Windows. I don't think so. Like, what do you mean? What kind of users? I mean, okay, you talk to a gaming PC them are running Windows. I don't think so. Like, what do you mean? What kind of users? I mean, okay, you talk to a gaming PC person, a gamer. Large, I mean, huge community. Gamers are huge communities. Steam is on Linux now, man.

Let's go. I mean, maybe it's diversifying, but still, by and large, they're building Windows-based PCs. Sometimes very reluctantly. Yeah, but gamers have one password. Maybe. Or LastPass, gamers have one password. Maybe. Or LastPass, or insert your password manager here. Like I said, I think, so my

argument is more so less like a direct comparison to Let's Encrypt, but more so the fact that the security of email password login for many, many people is paramount. And there's nothing out there like Let's Encrypt that's freely available to everyone. And that's what I mean by that. I think that if we had that, that was like one unified brand, one unified application like Let's Encrypt is,

it's a single unified brand to say SSL for everybody. If we had a version of that for email and password, I think we would have a better, a more secure world, maybe not so much less breaches, but certainly less people who have the same password across 17 services or just some layer above current state of art for security for everyday users. Amazing call to action, Adam. Yeah, that is good. Here's a lukewarm take. I think in 2025, which is the year that we are currently in, unless you listen to ChangeLog News, then you might still be in 2024. We shouldn't think about Windows and macOS and Linux very much at all. I think that Steve Jobs was right.

These are trucks. We drive trucks because we're truck drivers. But the world at large, the operating systems at large in 2025 are on smartphones. And iOS and Android are the operating systems of this decade. And so that's where it matters. And I think that those people for passwords are being taken care of. I can't speak to the quality of Android's implementation, but I know there's stuff there. And so I just think that we shouldn't even be thinking about desktops. And when we talk about mainstream consumerism, mainstream computerismism because almost everybody in the world using a smartphone as their primary and in many cases their only computing device hmm is that lukewarm is that hot is that cold i mean i don't disagree

that a lot of people a large majority of people consider computers or today's modern computer being a mobile device. It could even be as far as an iPad. Similar to this conversation with Dan and the fact that email, password, login will be around for the foreseeable future, I feel like some version of the desktop will be around for the foreseeable future. It is the platform where you have control of the computer, the operating system you know this jared you're a developer like that's my argument is like you will have a version of that for people i'm not saying you won't but those are the truck drivers and truck drivers have specific tools they use in order to drive their trucks better you know like remember that guy who's got the Sylvester Stallone? He had that built in.

Over the top. What is this? Oh, yeah, yeah. Dan knows. Gotcha. Or I was just thinking about a CDL, right? Like people... Well, yeah. You have specified knowledge, right?

And you have a higher expectation of a truck driver than you would of someone who drives a car. Yes. That's a more practical example. I was going for the movie reference. Remember over the top guys were Sylvester Stallone, he's got this built into his truck. He was an arm wrestler and he would use one hand and all day long while he drove, he would just be making that one arm strong. You know, take my strong arm. And he would become the best arm wrestler. It was basically a Rocky ripoff. Like Rocky was really successful. He's like, let's do it again with arm wrestling. And so he had a very specific thing in his truck where he could just like work out. That was over the top, Jared. I missed that movie. That was a good, I mean, the way he, I mean, so many people try to replicate.

We've got to get this on the screen. I mean, he would be arm wrestling them and then he would just do this movement and then take them down. He would just like curl his wrist a certain way. He would get serious all of a sudden and he would move his hands. It was like his killer move. You seen this movie, Dan? Yeah, he would like

change his grip. This is my favorite conversation about authentication, though. I'll be honest with you. Well, we aim to please around here. I love the movie reference. That's amazing.

But yeah, yours is a much more salient reference, which is specific tooling and testing and training that truck drivers receive in order to drive trucks well. And everybody else, we just, sure, we got driver's licenses, but we just hop in a car and drive you know we don't care about trucks so that answer like to kind of add on to the lukewarm take your response to adam is i don't care about yeah i mean we don't need a universal solution because we have one that is near universal for most of for the current um platform of the of the century basically is or at least decade maybe not century and

specific skilled users have their options as well and better education and they should know their choices of password managers and they should know this kind of stuff and the people driving the trucks today the desktop ccs and the macbooks and stuff are sophisticated users who have are usually working. I mean, most people are creating. Even today, a lot of creation is happening on device, but on smartphone, but are actually like, this is the working class people.

And it's not that I don't care about them. It's that I think that they are educated in ways that they can listen to the changelog and just know all the stuff or frankly like the employer might you know if they're an employer there's going to be exactly there's companies out there who specialize in this stuff yeah we should we should do a survey and maybe our audience is not the best audience but i don't know who else would survey besides our audience is like are you using a password manager we should survey someone else's audience

gosh i mean like i really want to know this because I feel like when I talk to everyday folks, if I even mention 1Password, like, what is that? Sure. And that's a failure on 1Password's part, in my opinion. Like, I'm not their marketing department. I'm not even their leadership. But I think if you're running 1Password, you want everyday users to recognize who you are because there's only so many, as Jared you are because there's only so many as

jared's saying there's only so many truck drivers but isn't the money and enterprise i mean yeah right businesses like like i know businesses that pay for one password and they're thrilled to pay for one password for all those reasons that you mentioned adam for sure yeah because you get everybody on the same platform you get a unified source of truth i'm not selling it but i mean all the reasons why you choose it is is is really good well you know it's a hard fight here you know it's a hard fight let's uh your lukewarm take though is is interesting all right good i feel like linux windows and mac os still matter that's because we are the truck drivers of the software world. Yeah. And we can even be a little over the top every once in a while.

Dan, if you were starting a software business today and you wanted people to authenticate against your website in order to do stuff, and you'd make money once they're signed in, and you want to make sure that they can get in and they can get their stuff but also their stuff secure and like what would your solution look like for a developer trying to build today yeah and so this is a great question because i think this goes back to that spectrum you talked about a while ago right and i think that

um if you have one single app and you have relatively simple software needs, I think that like going with the framework that is the base of your app is the right solution. Right. So with rails, that'd be devise with no JS. It might be like a passport or maybe like a service, like a Firebase, you know, because if you're kind of a single developer, you're just trying to get people into your app, right? And safe and secure. And a lot of these big services will take care of that. Where I think it makes sense to kind of introduce

something like Fusion Auth or Auth0 or any of those other kind of solutions we talked about is when it gets a little bit bigger, right? When you have more than one app or when you have, you know, there's that trade-off between build and buy and you always are kind of writing that tension of like, well, yes, our engineers could do this, but should they? And at some point, the answer is no, because they're better off writing features and not writing kind of undifferentiated login functionality.

So does that make sense? I mean, I appreciate the question because I'd love to be able to say, like, here's an answer for everybody and everything, but I just don't think that's the truth. So there is no silver bullet. I was hoping you'd just give us one. You could just tell us what to do.

Dan Moore told me to do this, and so I'm going to do it. But no, I had to actually think about my own use case and apply thought processes. That's no fun. Well, that even gets back to the way that people are offering to authenticate, right? I think that as much as Adam hates GitHub login for Tailscale, I think that's a great example of... I don't actually mind it. Just to be clear, I don't mind it. I think the screen presented is a little overreaching and I think it's overwhelmingly confusing.

I don't mind it. I think if you were writing an app that is targeted for small and medium business users in Germany, you should use Zing, which is like a German social business network. Or if you're writing something that is going to be deployed

to China, you should use WeChat. Or if you're writing something that's going to be aimed at business users in the US, you should use LinkedIn. And I think you should also have username and password as the baseline. And I think that you should offer other solutions that are going to reduce friction that let people choose. Because at the end of the day, again, this is from the lens of customer identity access management. You don't really care how people get in, right? You just want people to get in as quickly as possible so that you can get them to the value that they're actually hopefully going to pay you for. So you think that we're wrong because we don't offer email password as a base.

I mean, I would love to. Actually, that would be a great thing to survey your lose your listeners as well no he's gonna say listener and that's okay he's gonna say listener and he's gonna say user and he called him losers never invited back dan thank you very much no well to be clear dan is a former listener, now guest. He's been on twice, but he's listened to the show prior to being a guest. That's right.

He's in that bucket he's claiming. Go on, Dan. We're done joking. I mean, I think that there's probably a chunk of folks that do want to just use username and password, right? They want to put in one password. And there's probably a chunk of folks who'd be happy to use Google too. Because they have one personal Google account that they kind of hang everything off of. So that gets back to effort, right? And so how much effort would it take for you to add those additional login methods to ChangeLog?

And this is why we paid the big bucks, right? Because we're just guessing on what features are needed for the future. We can do surveys and ask people and whatnot, but you don't know. But username and password is such a baseline that it's hard for me to imagine not offering it. And I've definitely been turned off of places that didn't. Well, it's funny that you say that with the Google account. I didn't really consider it that, I guess, in this whole conversation. Because I don't think like others too frequently about this. I'm not an auth provider. I'm not a product manager for Fusion Auth.

So I'm not thinking about the way the product gets implemented. But I bet there's a lot of people out there who's like, you know what, Adam, you're an idiot the whole time you're having this conversation. I'm listening, but I love to hang every authentication off of my Google account because they are my password manager. Because I know how to get there, and it's literally one to get into gmail or whatever they're choosing and they they're effectively this free authentication provider or free one password manager or free password manager because they've logged into their email and everything is hinged off of sso and it's almost like hey if you don't offer sso with google then i can't then i don't even want to consider your service maybe there's people out there like that and that maybe is the free version of it that's available to everyone i mean i for my work we use google workspace and i prefer that right because

that way it's just it's super tied and i know that i will always have access to my google account as long as i'm an employee yeah and i can always if i get if i lose access to my Google account as long as I'm an employee. Employed, yeah. And I can always, if I lose access to it somehow, Google locks me out or something, at least I have recourse to my IT admins. Right. Personal is a little bit different. You hear horror stories about people losing access to their Google account and then losing access to like, you know, years of photos and memories and documents,

et cetera. But I loved for my professional accounts. If it's tied to my company, I love to hang it off my Google account. There is no one way to log in basically, Jerry, like that's the thing I think is, is we can,

we can bet on in 2025 and beyond is that there is no one way, unless you make only one way. That's right. Like we have. You go to changelog.com and you get your magic link. Here's the nice thing about it is we never expire that cookie, baby.

So do it once. Just keep your browser, you know, not flushed. And you never have to do it again unless you're switching to a different context. Every time you switch a machine, like that should be the first thing you do when you set up a new machine, right, is log into changelog.com, and then you're good.

That's right, and then you're just good to go for the remainder of that machine. Bam. Well, we didn't have time for it on this particular show, but there is a very interesting article out on FusionAuth's blog by Dan called Building a Self-Hostable Product. If you want more Dan Moore expertise, we'll link that up in the show notes for folks to go and listen to. Aside from that, Dan, what's the best place to connect with you on the internet? Yeah, so I'm

on Blue Sky. It's moreds.com on Blue Sky. I'm on LinkedIn, Dan Moore in Boulder is probably the easiest way to find me and FusionHot.io and I really appreciated the conversation, appreciated the movie reference. Maybe I should go check out

over the top. You should, man. That's an 80s movie, right? It's a classic 80s. Yeah, it's got all the 80s. 85, 88. I'm going to guess 88. Yep, riding Sylvester Stallone's Rocky coattails, you know, after Rocky he was kind of invincible there for a minute.

Let's see how accurate I was. 87. I was so close. Oh, man. I'm rewatching that. It's on my list now. That's a good one. All right.

That's all we have for today. Bye, friends. Thanks. Bye, friends. Did you know we now ship full video episodes to YouTube in addition to our award-worthy shorts and clips? So you can watch us have these conversations. If that's your kind of thing,

like and subscribe today at youtube.com slash changelog and share the channel with your friends, especially if they like to get their pods on YouTube like animals. One more thank you to our sponsors of this episode, Fly.io, Retool, Temporal, and Notion. Don't forget to check out their wares and support them because they're awesome and they support us, which is awesome. And of course, thank you to the one, the only, the beat freak, Breakmaster Cylinder for these dope beats. Next week on the Changelog, news on Monday, Bert Hubert talking long-term software development on Wednesday,

and another banger of a Changelog and friends on Friday. Have a great weekend, hit us up with a 5-star review if you dig it, and let's talk again real soon.