The Changelog: Software Development, Open Source
Over the top auth strategies (Friends)
Fri, 31 Jan 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 it at fly.io okay let's talk off
Well, friends, before the show, I'm here with my good friend David Shu 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 an 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 timer engineers, they wanted their engineers focused on building external facing software because that is what would drive the business forward. Breck's mobile app, for example, is awesome.
The Breck's website, for example, is awesome. The expense flow, all really, you know, really great external facing 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 awesome. honestly a wonderful partnership, and it has been for seven, eight years now.
Today, I think Brex has probably around a thousand Retool apps they use in production, I wanna 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 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. 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. Mm-hmm. Mm-hmm. 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 laughed, so you must know what he's referring to. N-A-C? I don't. I just love that one. 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, but it's... 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. And so NAC is an acronym. I think it stands for...
to try honestly but it replenishes your glutathione it's it like zaps a virus pretty quickly okay it's it supports immune health essentially got you so this is a shot you take is this food is it minerals it's a versions of that yeah it's like uh 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 embarrass myself publicly.
Yeah.
This is the problem with templates. 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 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. 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 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 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 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 it's 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. Um, 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. Yep. 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, I've hit all kinds of things that are just...
little sand in the gears huh a little bit a little friction just like oh yeah you know and so ultimately we're all trying to either augment or replace password base off you know because of the security concern it's just like so prevalent but and that 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 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, maybe. Yeah, exactly. Yeah. 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 yeah. 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 the change log or whatever they're doing before. And then they forget why they, why was that on the 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. And we've gone to some pretty extensive lengths to try to fix that problem.
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
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 well yeah we'll pre-click on links for you in order to do malware checks and 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, for a while, I was like, please don't use crap software. No offense. That didn't work. And 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. 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 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 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? Right. 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 users. 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 account's 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 right just off
It's nice that it's there. Cause 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, all this access, it feels very thick. I use Tailscale, and that uses GitHub for a good reason. 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. Like the, the whole entire tail net is built on my GitHub auth account essentially. Right. 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, it's a, 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 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 Authorize Tailscale. And at the very top, it says Tailscale by Tailscale. This wants to access your Atomstack account.
it's 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 want to off me to tail scale, 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 tail scale because tail scale asks for permissions.
All right. Tail scale fix this.
Yeah. Yeah. Tail scale. 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 TaylorSkills. 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.
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 and they needed to ask for a little bit more. Right. 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 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 are like, we may need, you know, the thing about just collect all the data we may need it in the future. That's easy to sell that in a meeting, I think. Totally. Yeah.
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 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 Tailnet upon that username and how you authenticate it. 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 going to 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 can't get in. Oh, yeah, I must have authed with GitHub because that's how it originally was, you know, six months ago when they first wrote it off. But I'm with you.
You know, I think that 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, 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. And I, But for a lot of customer-facing organizations or applications, that's just not reality. 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, uh, it's called a password safe. Um, March, not, uh, not, I think, uh, 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 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 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 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.
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 and it can also be shared you know, are 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 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. 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 of 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 an, it's a yes. And rather than a, you know, we're going to move entirely from this solution to that solution.
But 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, but it's newer. Okay. I would say over the last five years you've got like Work OS, 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, Key Cloak, Clerk, Zitadel, Ori. I mean, there's Propel Auth. There's a ton of these 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 did an Auth0 or Octobot Auth0.
October about zero for six and a half billion dollars.
So like that's past the startup phase.
And like 20, it was like 20 X there. 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 issues Security concerns around off now get offloaded, handled by a third party, hopefully in quotes, trusted or well-trusted, 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 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 if you escape a competitor who has a multi-tenant in SaaS, depending on their security posture, you may be able to access other users' systems, but you can't inside FusionAuth because it's separated. That's smart.
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 Postfix or I don't even remember those, you know, Sendmail.
And then Sendgood 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, you 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 with SpamAssassin and these other things on the public internet. Also, there's a step in between. 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. 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 cues, 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, cues.
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. 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 an 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 sum, but 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 it's, There's a click provided, so you can still just click on it and just embed 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 or 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 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. Like they have to fetch it every single time. But at least you're not stuck to like it has to be.
And if you're dyslexic like I am sometimes I read it backwards. I will misremember. I like 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. 1-6-0-5-8-0. I don't know.
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. Passkeys, however, you do not have to send a passkey 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. It's like, who's got the passkey?
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. Yeah.
you know if you're worried about people correlating things across like oauth or oidc you know the same thing is happening with past cases 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 uh for actually logging in is pretty good um it does you don't have as much control as a
the the thing that you're logging into the app you're logging into doesn't have as much control over like the 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 um 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, you know, character by character and making sure that things are all, all correct. So there's, 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, 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 passkeys 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 past word. I can share a past key.
I can create little subgroups in my family, like just my wife and I, or my kids and us like, 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 past keys. So what's been your experience?
Did you see my title change?
Yeah, that's why I said your title is not sold on Passkey, 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 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 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 want to 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 logging into Adobe's web services frequently and they that's their flow.
And I'm cool with Passkeys. 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 Passkey first, that I want to do email password or just anything else,
That service is sort of like force feeding me pass keys. And I'm like, you know, nah, man, email password. Okay. Now I do use one password though, as a, 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.
You don'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. 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? 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 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 password.
your username first right and that's so they can direct you to the right um identity provider if you're you know whatnot but like past 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, 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 pass keys. I understand the implementation for the most part.
And so I get it. But when it 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, they're like, hey, do you want to store a passkey? No, I just want to go through the door and shop.
I want to get what I came here for, right? Exactly. 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 for me that's not masquerading that's actually promoting it in a way that's a of a benefit to you because don't you want to wouldn't you rather just face id in than your name 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 1Password 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've got to keep it the one way. Versus, like, sprinkle your SSOs 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-ish 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 are or that past kids 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 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, Adam, right. And like, doesn't really understand kind of the big thing and they just want to get to Adobe and you can, you know, decrease it by 10 X that's, that's a big win for everybody.
Right. So, um,
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. 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 pass keys. 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.
Cause I mean like you're never not going to have one of these other scenarios, isn't it? There, there probably isn't a silver bullet because you always have all the ways, you know, essentially. But if you have a shared one password record, let's just say, so if you have a multi-user one password, uh, org or an account and you have a password or an authentication, it's shared with somebody else, uh,
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 manifests 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 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 a separate... And my guess is 1Password kind of segregates that stuff inside their own system, right? So that an attacker coming in, 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? 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. Like, don't make me think. Like, no, they're making you think. I think it's by design.
Like, it's really hard to authenticate a new device and sometimes even into itself. Like, the password itself can be very long. It can obviously be if you're on a new Mac kind of thing, you can do your Touch ID into it, which I love. I mean, I think just Touch ID authentication, one password to me is like the way. I mean, every Linux user bowed 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.
Uh, let's see. How worried am I on this? You want to do a scale of one to 10?
Well, and obviously it depends on your account, right? Like there are probably accounts that you don't care about, right? Like, but let's say your bank account, like how, how much is that? Were 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.
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 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. So... Five, maybe. Five. Okay.
And I just want to say, 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... 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. 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, um, you know, using them in passwords being pulled from password manager and then using a different software authenticator app, like Google authenticator off the, um, There's some open source ones out there, even sending SMS.
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, if you're not, the IO is my login identifier, then Dan and 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 you said, kind of has some problems with security?
I mean, I assume... SMS or email, right? Like anything that's deliverable is probably going to 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 um 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 that Adam could probably install as an extension to 1Password. And then he's just kind of circumvented that whole thing again.
right so right 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 example and you know answer this is like you say um you know 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, OK, for example, my my Traeger smoker, I can put it on my Wi-Fi and there's an app that lets me control it from far away. Well, apparently it can't do a Wi-Fi pass with this 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, because I'm crazy. I don't give it out. 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 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.
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. complex, right? Like they'll just add like the one exclamation point at the end of a normal word or something like that.
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 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 going to give you a peep behind the scenes here. We love notion here, 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, 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 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 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 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, 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 pass keys do it in a way that's a little bit more opaque and and not maybe as compatible, but is a little bit stronger because it's private public key encryption. Whereas password managers are more designed to fit in with the world we currently live in and have all these nice add-ons that you mentioned, Adam.
just don't i don't say whatever the basics man just just you up just password management it would be great uh doesn't have to be the otp you know 2fa kind of integration the one patch 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 going to go anywhere except for on channel.com like you're gonna like that'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 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, you know, 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. 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 has a built-in password management and has been there for a couple of 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 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 until a couple years ago. Until a couple 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 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 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 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. I'm just sad for them. It's a mess. They installed so many softwares that are 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 lead 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, you know, 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.
would also say like i think that you kind of hit or you alluded to one of the issues um with this even if it gets installed in apple in apple's um 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.
Um, it's different than less 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 it's off 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. Yeah. 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 Authenticate, I'm looking at it. Baseline. It's the, it is a line beneath the base. 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 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. What are you going to do? You wrote an app. You have an old app that you're not going to rewrite. Entrenched.
Yeah. 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 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 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 Mac OS 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.
Hmm.
Is that lukewarm? Is that hot?
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. I 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.
Dan knows. Gotcha.
Or I was just thinking about a CDL, right?
Well, yeah.
You have, you know, specified knowledge, right? And you have a higher expectation of a truck driver than you would have someone who drives a car. Yes. Yeah.
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 would like, 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?
Yeah.
He would like, no, but like change his grip.
This is my favorite conversation about authentication though. I'll be honest with you. I love the movie reference. That's, that's amazing.
But yeah, yours is 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 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 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, I don't care about them is that I think that they are educated in ways that they can, 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 we 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 one password, like, what is that?
And that's a failure on 1Password's part, in my opinion. 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'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 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. Your lukewarm take, though, is interesting. All right, good. I feel like Linux, Windows, and macOS 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, 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, um, no JS, it might be like a passport or maybe like a, 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 tradeoff 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
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? Like, I think that, you know, as much as Adam hates GitHub login for Tailscale, I think that's a great example of- I don't actually mind it.
Let's 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 are 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 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 always 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 listeners as well.
Are losers, Dan?
Oh, I didn't say... No, he was going to say listener and user. He was going to say listener and he was going to say user. And he called them losers.
Never invited back, Dan. Thank you very much.
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 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, yeah. that gets back to effort, right?
And so like, how much effort would it take for you to add those additional login methods to ChangeLog? And if the effort, this is why you paid the big bucks, right? Like, cause 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 just in 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 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 1Password to get into Gmail or whatever they're choosing.
And they're effectively this free authentication provider or free 1Password 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 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 and I can always, if I get, if I lose access to it somehow, um,
know google locks me out or something at least i have recourse to my it admins right um personal is a little bit different you hear horror stories about people losing access to google account and then losing access to like you know years of photos and memories and documents etc but um 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. That's the thing I think we can bet on in 2025 and beyond is that there is no one way, unless you make only one way.
That's right. Unless you go to Chainsaw.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 not flushed, and you never have to do it again unless you're switching to a different context.
Every time you switch a machine, 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 check. 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 fusion.io. And I really appreciated the conversation, appreciated the movie reference. Maybe I should go check out over the top.
87.
I was so close.
Oh man. I'm rewatching that. That's on my list now.
That's a good one.
Thanks. 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 five-star review if you dig it. And let's talk again real soon.