Over the top auth strategies

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 it at fly.io. Okay, let's talk auth. Well friends, before the show, I'm here with my good friend, David Hsu 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 tool 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're 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 phasing software because that is what would drive the business forward. Brex mobile app, for example, is awesome. The Brex website, for example, is awesome. The Brex expense flow, all really great external phasing 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 1,000 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 of 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 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 that really matters for you and your team. Learn more at retool.com, start for free, book a demo, again, retool.com. 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. And Adam's also here. Adam, welcome back. Man, I'm so glad to be back. I love this show. It's so awesome 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, so you must know who he's referring to, NAC? I don't, I just laugh when I don't know what's going on. That was a pity laugh, Adam. You've missed us both with this. Is NAC not another character? I don't know, what's NAC?

It's an acronym, obviously, and I cannot pronounce it, but it, so there's a lot of speculation in the medical industry, because there's a lot of suppression of 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, if you wanna try, honestly, but it replenishes your glutathione. It zaps a virus pretty quickly. It supports immune health, essentially.

Got you, so this is a shot you take? Is this food? Is it minerals?

It's a version of that, yeah, it's a pill, you know? Similar to like maybe, like magnesium might be, 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 wanna try it, but I tried it. I didn't wanna try it, yeah, I was like, nah.

Jared's not afraid.

Too many letters. We 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 embarrass myself publicly.

Yeah.

This is the problem with templates, you know? You build yourself a template, and then you use a template, and the template probably supports 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 really good, so I just rolled it.

I bet it did. You're like, yes, this sounds familiar.

Oh, yeah, 2024.

Yeah.

Ah, 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 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 Fusion Auth, 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, 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 learned about OAuth, and SAML, and OIDC, and JOTS, basically alphabet soup in terms of jargon, but spent a lot of time decoding that and 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 build versus buy decisions, because at its simplest, it's completely a build thing. It's a solved problem at its simplest case, right?

Totally.

But then the thing is is there's this sprawling concern that happens over time with it, where just the simple case 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 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, are passwords dead? We've got excited about pass keys, Adam, you and I last year speaking with 1Password folks. Is that right? It was. Yes. 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? Little frictions.

Yeah, just like, oh. Yeah. And so, ultimately, we're all trying to either augment or replace password-based auth because of the security concern. It's just so prevalent, but...

And I actually want to ask you, 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 gonna visit all the time. You're gonna come in, subscribe, unsubscribe, comment.

Once every couple of years, maybe.

Yeah, 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 gets a little bit slower than a password manager.

Enough time for people to be distracted, right? And like move away, go back to Hacker News or listening to the change log or whatever they were 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, 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. And we've gone to some pretty extensive lengths to try to fix that problem. But 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 a while for the email to be delivered or the email is being read by something else and expiring a one-time code or something like that.

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'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, will yeah, will 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 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, for a while, I was like, please don't use crap software. No offense, no offense to anybody who uses it, but to the software itself, it's just not good, email software. But then I'm like, well, you can't, you can only say that a couple of times. And then like the sixth, seventh time, I'm like, I gotta solve this problem. It can't be that hard. And so it's like, well, I guess I just require JavaScript. I just changed that till 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 expired after a bit then? You expired after the first click?

Is that the common case? Well, it's a one-time magic link. And so once it gets used, you can't, you don't want it to still work.

I mean, you could build in some kind of like slot factor, let it happen two times or three times, but it is the entry point into your application. And there's definitely some worries around that. So 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, 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 changelog 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. Cal.com, right? I'm going to sign in with my Google account because 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 Adam, you're the same way.

Even so, like 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, like if you're listening to GitHub, that's a bad page. Like it needs to, it's always overwhelming and confusing. And I feel like I have no control over what I can and cannot share, just the auth.

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-writes, like all this access, it feels very thick. Like Tailscale, I use Tailscale and that uses GitHub for a good reason. I use GitHub as my, I don't know if they call it actually what their terminology is, but it's not built on my Google SSO, it's built on my GitHub SSO. So it's built on that auth. And I don't know how to describe it. Like the whole entire telnet 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 my repo places where I do open sources, where I do proprietary code. It's 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 Tailscale 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. And at the very top, it says Tailscale by Tailscale. This wants to access your Adam Stack account. Its existing accesses read org and team membership and read org projects. So I'm like, okay, why do you need to have, like if you just wanna auth me to Tailscale, why do you need to list my team memberships, my org projects, like 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.

Sure.

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 Tailscale. 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 auth.

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 into this.

It might be the GitHub API too. You know, that's just how it works.

It's like, yeah, how core screen 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 needed to ask for a little bit more. And there was another use case. They need to ask 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 based on kind of what I've seen over the years is best of intentions, but GitHub having core screen permissions makes it really tough to like ask for just what they need.

Right, and sometimes the other strategy, 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 it, just collect all the data, we may need it in the future. It's easy to sell that in a meeting, I think.

Totally.

Sure, and ask for more than you need, come back later, never. Right. I always felt like GitHub auth was, it felt, anything 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 wanna have to go to every website and think, which provider did I create an account with? You end up with like two accounts on different places because you tried this, then you try your email,

and you're like, oh. And so I'm just like, if I just use email everywhere, then I never have this problem again.

Exactly, that's my basic premise is that. But Tailscale 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 wanna ever think like, how did I auth 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 can't get in. Oh yeah, I must have auth with GitHub because that's how it originally was six months ago when they first wrote auth. But I'm with you. I think that you asked 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 worlds 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, I may not be an inbox zero guy, but I'm definitely a segregated and separated inbox based upon 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, depending on your audience, that could be a viable path. But for a lot of customer-facing organizations, 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 her 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, who are you then?

It's called a password safe. Who's the Schneier guy, Bruce Schneier recommends it, and it's open source and just kind of super dumb. But it's not integrated with any external systems, because that's the other worry that I have with password managers, like 1Password or LastPass we've seen, is they are super valuable targets, right? Because they have everything.

For sure.

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 gonna 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, in so far 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, okay?

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 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 any costs will be shared or discovered by an attacker. I think you need to, as someone holding passwords, right? 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 that just the reason is that it's lowest common denominator, right? Like I have definitely like tail scale 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 you can class of applications like games are perfect example. Games don't need to know your real identity. 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 with people who are willing to kind of log in. And that includes what we talked about magic links. We talked about social login. I think we're going to talk a little bit about pass keys and it's a yes and rather than a, we're going to move entirely from this solution to that solution.

But certainly bolster 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, but it's newer. I would say over the last five years, you got like WorkOS, you've got obviously Fusion Auth, you've got Auth0, 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, Keycloak, Clerk, Zitadel, Ori. I mean, there's Propel Auth. There's a ton of folks out there doing that. Totally.

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 Auth0 or Okta bought Auth0.

Okta bought Auth0 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 startup to scaled up. Totally. Yes. Yeah. Point is, is that now it's so complex to do Auth that we now need to offload 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 turned 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.

Sure.

You know, 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.

Well, you also end up in the same situation

with 1Password and LastPass. When now these providers become huge targets, of course they probably have their security teams, you know, staffed up because if I can hack into Okta or FusionAuth or whatever, it's not just one company's stuff I'm gonna get. You know, it's like a smorgasbord.

Well, so I wanna, actually I wanna 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 or?

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, you know, depending on their security posture, you may be able to kind of access other users systems, but you can't inside FusionAuth because it's like separated. You know, it's a separate database. So, but I do wanna talk to, I mean, Adam was talking about like 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 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 gear head 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. Having done both, I can tell you that rolling your own auth is considerably easier than operating a post-fix server and with spam assassin 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 usually 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. They deliver 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, et cetera, 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. So let's go back to Magic Links and talk about OTP because this is kind of, to me, seems like maybe a evolution of Magic Links and an improvement. So the idea here 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 MD5, but 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 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 switching context aspect, which a lot of people run into is like, hey, I'm on my phone, I sent myself a Magic Link and I don't have that email app on my phone. There's all these different weird things where it opens in an 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 can solve that by just either copy pasting 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 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. Like they have to fetch it every single time, but at least you're not stuck to like, 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,

one, six, zero, five, eight, zero, like whatever, right? And I feel like that's also an attack vector because like maybe it's somebody sitting next to me and I'm like lightly whispering this password that is only on my screen. One, six, zero, five, eight, zero. You know, I don't know. Yeah, I always feel concerned about that. 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 trying to get me.

Yeah, I mean, OTPs are a great solution for sure. I mean, they still share some of the issue with magic links, right? Like in terms of the deliverability, like timeframe and a little bit of discontinuity there, but they definitely step around a lot of the other complexities, whether it's browser-based stuff or the link checkers or whatnot.

Yeah, absolutely. So you still run into that stuff. Pass keys, however, 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 pass key, you hold the pass key, and as long as you have the pass key, 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 pass key stuff, I'm not sure we're gonna get into that because this is where pass keys get weird, is like, who's got the pass key? 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. One is like how you set them up, first of all, kind of 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. If you're worried about people correlating things across like OAuth or OIDC, the same thing is happening with pass keys that are shared, or if it's by 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 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, character by character and making sure that things are all correct. So there's two kinds of security benefits for pass keys, for sure.

And yet people don't seem to like them for some reason. So I have had nothing but positive experience with pass keys as an end user. And I should say that my stack is basically Apple stack. I want an iOS and Mac OS. And I use the passwords. It's now it's on an 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?

Yeah, that's why I said, it's not your title is not sold on pass keys. So I knew you weren't.

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 pass key scenario. I also find that services are defaulting to pass keys and it like bothers me. When I wanna be a email password person, it's constantly just slapped me in the face, like, where's your pass key? And I'm like, nah, man, I'm doing email and password, okay? And it just seems like always wanna default to this thing. Adobe does it. I sign into the document cloud a lot for like 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 logged into Adobe's web services frequently and that's their flow. And I'm cool with pass keys. 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, pass key first, that I wanna do email password, just anything else, that service is sort of like force feeding me pass keys. And I'm like, nah, man, email password, okay? Now, I do use one password though to just identify my stack. So unlike Jared, Apple, simple, free, you know, 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 and I 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 and that's cool. I use one password for a lot more than passwords. Like 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? It would be really bad. It would be really bad if one pass 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 pass keys, right? Like usernames and passwords have been around for a long, long time. 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 pass keys, 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, let me try to define some of the other user flows that have bugged me. And 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 pass keys, I understand the implementation for the most part, and so I get it. But when it ends up happening 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 have authenticated with username and password, they're like, hey, do you want to store a pass key? No, I just want to go through the door and shop.

I want to get what I came here for, right?

Exactly. Don't ask me do I, and don't be secretive about it 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.

For me, that's not masquerading, that's actually promoting it in a way that's of a benefit to you. Because wouldn't you rather just face ID in than username 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 a service? And maybe next time it's just so automated because the way one password works, the way Apple passwords works, maybe I won't care. But something in me says, no, Adam, the way you authenticate is this way and you got to keep it the one way versus like sprinkle your SSOs around and then I'll see your potential email and passwords. So I'm like, nah, I'll just keep it the way I want to keep it and stop bothering me about pass keys. 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 pass keys usage on my Adobe login. The flow is kind of weird though because I will authenticate with the pass key, 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. There's not a lot of user experience visually to say the pass key 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-ish seconds later, roughly.

I did want to say like, I don't think it's just for security. That's not the only reason that new orgs or that pass keys 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. There was something I'll share the link, but this person referenced a Microsoft study that said that the average time to log in went from 69 seconds with username and password, slash MFA to eight seconds with pass keys. And so if you can get someone into Adobe quicker, especially someone who doesn't, like doesn't have your depth of experience at them, right? And like, doesn't really understand kind of the big thing. They just want to get to Adobe and you can decrease it by 10X. That's a big win for everybody, right? So.

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. It's like 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 pass keys, I feel like you're gonna always have every way to log in. That's why I feel like FusionAuth has such a long game here because I mean like you're never not gonna have one of these other scenarios, isn't it? 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 Bitward 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 truth 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 a separate, and my guess is 1Password kind of segregates that stuff inside their own system, right? So that an attacker coming in and getting access to the passwords would have a harder time getting access to the TOTPs.

I have a really hard time getting access to my own 1Password, okay? Like if, to add 1Password onto a new device, it's not easy. It actually makes you think quite a bit. It goes against everything Steve Krug said way, way, way back in the day with user experiences. Don't make me think like, no, they're making you think. I think it's by design. It's really hard to authenticate a new device and sometimes even into itself. The password itself can be very long. It can obviously be if you're on a new Mac kind of thing, you could do your touch ID into it, which I love. I mean, I think just touch ID authentication to 1Password to me is like the way. I mean, every Linux user bowed down to the way. It's just, nah, 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 macOS' 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 a scale of one to 10?

Well, and obviously it depends on your account, right? There are probably accounts that you don't care about, right? But let's say your bank account, like how much does 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. Now that you've said this, thank you very much, I guess my concern is elevated and I think it goes back to the level of trust that I give to 1Password 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 to Feras, Jared, back in the day when he was doing wormhole and all that stuff, he was like 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 guess at that point, I'm not that worried about it, honestly. Five, maybe, five.

Okay, and I just want to say, and I just want to disclaimer, I don't know anything about 1Password, right? I'm not attacking them in general. It's like the general principle of MFA.

I think we should. I think they should be scrutinized. I think we should hold them. No, I really do. I think they actually, I think they welcome it. Because 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? Would it be, what would that look like?

Yeah, I mean, I think that it does depend. I've actually wrote a blog post about this, about the different kinds of MFA for customers, right? Again, employees are a different world because you can force them to do all kinds of stuff and you can spend money on it.

Right, carry this YubiKey around.

Totally, totally. But for customers, I think an important thing is that it is going to at least a different piece of software, right? So, username and password, 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. 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, like 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 Dan at FusionAuth.io as my login identifier and then Dan at example.com as my MFA. And again, you're just separating things out and you're not, 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 it's not to, if there's a state level attacker out there, hi, anyone who's listening from a state level 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, 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 can 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 you said, kind of has some problems with security?

I mean, I assume SMS or email, right? Like anything that's deliverable is probably gonna be outside of your app. 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 1Password or Orbit Wardener, et cetera. So yeah, so you definitely can help foster things by using deliverable methods. That's really the only way you could 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 1Password. And then he's just kind of circumvented that whole thing again, right? So, 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 to this. It's 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. Well, 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 Traeger smoker, I can put it on my wifi and there's an app that lets me control it from far away. Well, apparently it can't do a wifi password that's longer than 30 characters. And so obviously my wifi password is probably like at least 32. I think it might be 64, honestly, because I'm crazy. I don't give it out. It's, you know, it's our hand type and my wife hates it. It's not 64 characters, but it's probably 32. It's a mess. I'm not saying it's the best solution ever, but my Traeger 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.

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 check the corpus, right? Like there's a bunch of corpuses of 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 here at Change the Law. 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. 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 and 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, 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 one password doesn't have a free tier, because you would think that would be a phenomenal attractor and the fact that 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 could put in one password, lots of cool stuff. But I feel like password managers or password management is the new SSL and 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'm not sure we're there because let's encrypt. The big 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, 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 verifiers of identity. And pass keys do it in a way that's a little bit more opaque and not maybe as compatible, but is a little bit stronger, right? Cause 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, I don't see the lever there.

The basics, man, just password management. It would be great. Doesn't have to be the OTP to a fake kind of integration just let me, let the world have access to what I would, maybe I don't even agree with this. Like email, password, login is probably not gonna go anywhere, except for on change.com. Like you're gonna, 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 change login for myself with that cause like I don't need to store it. There's nothing to store. But in so far that so many services out there and already 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, I was gonna say, cause 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 there's places you can go to get better ones. And iOS is a built-in password management and like has been there for a couple of years now. I don't know what Windows does cause 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 talk. 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 till a couple of years ago.

Till a couple of years ago. So I recently 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 gonna put on there and do all this work is Windows. And that's just like the sadness of my life. I would never wanna 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 an 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 like clicking on here. Yeah, right?

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 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 somebody's gotta do this and who's gonna 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 1Password for free is not very smart, although it could be the Xerox of 1Password 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 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 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 kinds 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 Affinity, I'm looking at it, baseline. It's the, it is a line beneath the base. You know what I'm saying? I don't think, 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 like up into the right opportunities. And Windows is just kind of like last millennia's thing. Like it's just there. I don't know how they get away with that.

Large installed base that, 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?

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.

Gamers have one password. Maybe. Or LastPass or insert 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 really available to everyone. And that's what I mean by that. It's like, 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 computerism,

because almost everybody in the world using a smartphone as their primary and in many cases, their only computing device. 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 compute, control of 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, you know, he had that built in over the top. What is this? Oh yeah, yeah, yeah.

Dan knows. Or I was just thinking about a CDL, right? Like people, you have specified knowledge, right? And you have a higher expectation of a truck driver than you would have someone who drives a car.

Yes, that's a more practical example. I was going for the movie reference. Remember over the top guys where 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 rip off. 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 miss 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've seen this movie, Dan? He would like change his grip.

This is my favorite conversation about authentication though. I'll be honest with you. All right. Well, we aim to please her out 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, you know, 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, I mean, we don't need a universal solution because we have one that is near universal for most of, for the current platform of the century, basically, or at least decade, maybe not century.

And specific skilled users have their options as well. 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 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 change log and just know all this stuff.

Or frankly, like the employer might, you know, if they're an employer, there's going to be like-

Exactly, there's companies out there who specialize in this stuff, yeah. 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. It's 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 part in my opinion. Like, I'm not their marketing department, I'm not there 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's saying, there's only so many truck drivers.

But isn't the money an enterprise?

I mean-

Yeah, right. Businesses, like, I know businesses that pay for 1Password and they're thrilled to pay for 1Password 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 really good. Well, you know, it's a hard fight here, you know, it's a hard fight. Let's- Your Luke Bourne take though 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 make money once they're signed in, and you want to make sure that they can get it 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 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 Node.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 riding 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 gonna 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? Like, I think that, you know, as much as Adam hates GitHub login for tail scale, I think that's a great example of- I don't actually mind it.

Just to be clear, I don't mind it. I don't know, you seemed pretty upset earlier. I think the screen presented is a little overreaching and I think it's overwhelmingly confusing.

Fair enough, fair enough, fair enough.

I don't mind it.

But I mean, I think if you were writing an app that is targeted for like small, medium business users in Germany, you should use Zing, right? Which is like a German social business network, right? Or if you're writing something that is gonna be deployed to China, you should use WeChat. Or if you're writing something that's gonna 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 gonna 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 listeners as well. Our listeners?

Our listeners did.

Oh, I didn't say that.

No, he was gonna say listener and user. Frootiest lip, that's okay. He was gonna say listener and he's gonna say user and he called them losers. Yes, listener users. Never invited back, Dan. Thank you very much.

Oh 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. So he's in that bucket, he's claiming, go on, Dan, we're done joking.

No, I mean, I think that there's probably a chunk of folks that do wanna just use username and password, right? They wanna put it into 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 like how much effort would it take for you to add those additional login methods to change log and if the effort, 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 like think like others too frequently about this. I'm not an auth provider, I'm not a product manager for Fusion Aw, 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 password to get into Gmail or whatever they're choosing. And 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 don't even wanna 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 super tied and I know that I will always have access to my Google account as long as I'm an employee. 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. Personal is a little bit different. You hear horror stories about people losing access to their Google account and then losing access to 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, Jared. Like that's the thing I think is 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 actually go to change.com and then 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 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 in to change log.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 mooreds.com. I'm Blue Sky. I'm on LinkedIn, Dan Moore in Boulder is probably the easiest way to find me and FusionAuth.io. And I really appreciated the conversation, appreciated the movie reference. Maybe I should go check out over the top.

You should, man. God. That's an 80s movie, right? It's a classic 80. Yeah, it's got all the 80s. 85, 88, I'm gonna 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. That's a good one. That's on my list now. That's a good one. Thanks, Dan. 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, Burt 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 five-star review if you dig it and let's talk again real soon.