Security without speed bumps: Making the secure path the easy path
Dennis Henry (Okta) discusses how endless approvals and security hurdles slow you down and make things less secure.
Dennis Henry, Productivity Architect, Okta
The transcript below has been generated using AI and may not fully match the audio.
But thank you everyone. my name is Dennis Henry. I use he, him pronouns, and I am a productivity architect at Okta. very new position that I kind of made myself very recently, but I am a, let's call it recovering, SRE. the vast majority of my career, I worked in incident management. This is actually the first time over a decade.I'm not on call right now, I'll be having way more drinks, after this than most of you. but yeah, I'm here to talk about security and more importantly, the relationship of security and productivity, because I think most people think of those two things. They're like two circles that are completely separated and there is no Venn diagram that even connects them.Like a secure tool cannot possibly have a good user experience, cannot possibly. Be fun to work with or anything like that. But I'm gonna tell you a story. And the story kind of starts with a login prompt. Everyone loves those, right? Everyone has a login prompt, at least what, like 80 times a day? They're kind of annoying.and what it does is it cause people sometimes to route around that pain. we all know this concept of shadow it, we all know this concept of whenever an engineer is hit with something that bothers them. They typically engineer a solution around it, not a great thing. they invent shortcuts or sticky notes or disabling their prompts.Not outta malice mind you, but it's more about load management. And there, there's a lot of studies that kind of talk about this idea, and NIST has a great one all about security fatigue. But what it does is it causes these frictions, these workarounds and most importantly risk. So what is security friction?Security friction is this concept that is anything that really just taxes your limited human attention and memory. It, everyone has internally this thing called a compliance budget. You will comply with certain policies and procedures as much as you can up to a point. And when you go over that point.That's when you kind of lose that finite tolerance for security. And now you go around that. Endsley wrote a really good paper about situational awareness and talks about this concept of how you can maximize security awareness by reducing friction and most importantly, limiting cognitive load. So the big thing I wanted to talk about is when strong security backfires.And let's talk about this push base, MFA spam. If you get a lot of these push base MFAs where you're going and putting your fingerprint on that goddamn touch ID reader over and over again, at a certain point you stop even reading, what the hell am I even approving? I'm just saying, yes, I don't know what it is.And that will lead to significant risk. What it does is when you are basically making someone do something that they don't want to do, change your password every—what are some of the crazy ones I've seen, like every month? That is always going to make for a much less secure environment because your passwords are gonna get weaker and weaker. You're just gonna add another freaking one to the end of your password. Oh, I know you do it. I know you do it, and what it does is it causes security fatigue. And the behaviors that result from this are incredibly risky. And again, NIST really highlights this in one of their papers that talks about just the resignation of people that, that just, they wanna do the right thing, but they are just so freaking annoyed that they are now doing the wrong thing.So I do want to differentiate because there is good friction. There is good friction. There's bad friction, good friction. Phishing resistant. MFA factors like having to do an MFA is not bad friction, it's friction 'cause it's causing you to have an interrupt. But doing it once in a while, maybe once every four hours or something like that's tolerable and it's good because it is verifying with another state that you should have access to what you are trying to access.Device-bound signal, something that is verifying your computer should be able to access a certain thing. Again, great security thing. WebAuthn, awesome. What is bad is repeated prompts. Long-lived tokens. Again, this is something that having like a plain— which again I'm looking around. Almost all of you have this, a plain text NPM token sitting on your computer.An .npmrc. This is a terrible thing because it just lives forever. All it takes is that computer getting compromised, and then you can see what happens. If you were following the news recently with all the NPM hacks, copy and pasting secrets, this is not a good thing to have to do over and over again.Password managers exist, that's great, but it's still not a good thing to have that going in and out of your memory. It's just not a good thing. The goal that everyone should have, strong by default, and most importantly, minimal user effort. And this is born out in statistics, and these are not just pulled out of a certain layer area.these are actually real statistics that there are 99.9% fewer compromises with companies that have MFA enabled versus companies that don't. Real statistic—I can't remember where I got it from, but trust me—there's also 50% fewer account takeovers when you have a second factor implemented.So the, there's just a pattern here. If you remove friction and you bake security into the default path, you will ultimately allow for a more secure company. Defaults matter more than training. Oh, it was Microsoft. That was 99.9%. Thank you for putting that on the slide after Dennis. Good job. In any case, it is incredibly important to have sane defaults that allow you to have the secure environment, but in such a way that you're not causing additional friction.So let's talk about some case studies. MFA fatigue is something that I talked about a little bit, but I'm gonna dig into a little more. In 2022, there was an attack—are there any people that work at Uber here? Cool. I'm gonna shit on Uber. There was an attack at Uber where an attacker used push bombing and social engineering to basically gain access to his own computer.They were just pushing and pushing, and the person was just clicking because they were so used to it. And again. I'm not ever going to blame someone. I'm never gonna blame the victim. I did read the, blameless postmortems and all of that kind of stuff, but again, this is just something that we all will do and I would, do it too.And the fact is that if you build in a better system that allows for the right amount of friction, but not the wrong amount of kind of annoyance, you will ultimately allow for a broad. Change of your company towards this more secure environment. There is really a very easy way to stop push fatigue. and if any of you and your companies, which probably a lot of you use Okta, please talk to your Okta administrators because there's ways to fix this.You can enable number matching, you can enable rate-limiting. You can enable a timeout where after a certain period of time of doing an MFA, you don't have to do another one. Very easy. And more importantly, you can adopt phishing-resistant MFA—WebAuthn passkeys. Again, these are in such a way that you don't have to worry about these passwords changing all the time or anything like that.Contextual prompts. Making sure that, okay, maybe if the person is in their same location that they always are, they're not in some brand new location. Maybe I'm not gonna MFA them, but if they're suddenly in I don't know, Shanghai, when they're normally in Florida, maybe I'm gonna prompt them for an MFA, because that's a little weird.That's the kind of thing that I'm talking about here, and these are all configurable and really the best path for introducing the best possible phishing-resistant MFA. And again, passkeys, absolutely amazing. They're device-bound. They're also origin-binding. They block phishing attempts and just get a really fast sign-on, fewer prompts.Everyone's happy and everyone's more secure. Again, we're talking about friction here. So this goes back to the concept of zero trust. You always want to basically assume that access always needs to be evaluated, but not in such a way that access needs to be evaluated. Evaluated in line. What I'm talking about here is.the requests are validated, but what they're doing is looking at measurements on the computer. They're looking at where the person is, looking at the last time they MFA'd. They're looking at all of these metrics to make sure that this is actually a time that I should prompt or not—that every single time they're evaluating it, always assume that the person shouldn't have access, and then figure out if they should. Another thing that is really important is internal tooling. User experience matters. This is something that I see all the time. Companies focus so much on their product's UX that they forget to care about their internal tooling's UX, and this matters because of the fact that these internal tools—which all of us have; internal tools that some guy that worked here eight years ago built and now just is the thing that is the backbone of your company—that is always going to be the tool that gets compromised because of the fact that it is just a very poor user experience almost all the time—that is the case. Or even worse, it doesn't even have very good security controls built in. But the whole thing is we need to be caring about this internal tooling user experience, removing copy-and-pasting secrets, and more importantly, automating the sunny path.And I'm going away from this concept of happy path 'cause I just don't like the way that sounds. The sunny path. And y'all can steal that, please. I'm making it a thing here. So another case study, Docker authentication—Docker stores creds. and I don't know how many of you people know this, but all of Docker's credentials are stored in base64 in your config.json, and that is all—and base64 is not an encryption algorithm.I don't know why people think it is. It's an obfuscation algorithm, but it's not an encryption algorithm. Everyone can base64-decode an encoded string. It's terrible, but you can do things like build credential helpers that allow for short-lived tokens, and you can have OAuth or just-in-time minted tokens to avoid storing these long-lived tokens and reduce the login loops because at the end of the day, okay, say for example, you're using Docker auth, but I'm making sure that I have short-lived tokens.You have to do it every day. You have to do it every day. You have to log into Docker every day. That is not something that your users are going to do. Happily, they'll do it begrudgingly and they'll start finding ways around it. So that's where this final case study, which is a tool that I developed at Okta called the Okta Credential Manager, that I am very much trying to get open-sourced.but it's a tool that I created that allows for automatic OAuth and SSH for GitHub, short-lived Artifactory and CI credentials via our internal authentication and resource management, and it handles Git, Docker, NPM, pip, Brew—basically anything under the sun. And what it does is it allows people to have these authentications in such a way that they don't even realize that they're authenticating.It is such a low-process or a low-risk maneuver for them that they're just authenticating and they're getting these really short-lived four-hour tokens. But it's being done in a secure way that's verifying these low-level signals that make sure they should be able to access what they are trying to access.So you can do things like—just all they have to do is ocm install and then use their normal CLI. They can get these tokens whenever they want by doing things like ocm auth artifactory, ocm auth github, and they have these tokens readily available for them, but not stored in flat files; rather, they're stored in the secure vault on Mac, and I forgot what the hell it's called on Windows.Who uses Windows anyway—sorry for any Windows lovers. I didn't know there were any, so again, the security wins here are clear: short-lived, scoped tokens, which is also incredibly important. The tokens that it mints are scoped specifically for whatever you're doing at that moment. So it allows for a verysecure token storage. It also has a centralized policy and audit structure, and it also completely eliminates this concept of token sprawl—meaning all of your tokens are all over the place in all these goddamn flat files, which if you actually wanted to redact them all, how the hell are you even gonna do that?The secure path becomes the easy path, and what's really important is measuring the friction. So all of this to be said—rewinding a little bit—I'm a human factors practitioner. I am three weeks away from getting my Master's degree from Embry-Riddle. So measurement of this friction is incredibly important to me because it helps us understand why we do this, how we are impacting the human element of this—really, this situation.You can measure it by looking at like time to first clone, which is also a really important thing. Hopefully they can do it within the first day. If you have a very complex GitHub, onboarding process, maybe that's a week measuring that is really good. All failures per day per, per, developer per day.Also, a really good way to understand—and more importantly—token sprawl index. And this is something that maybe is a little harder to do here, but understanding how often or how many tokens are present on your employees' workstations. This is something that, again, you have to assume that an employee's workstation is gonna be stolen or lost at some point.That is a massive security issue if those tokens are long lived. So understanding how you are burning down these long lived tokens, sitting on these computers is incredibly important. You can even pair this with Dora outcomes. You can look at the, kind of MTTR and this kind of stuff to show impact of this work.At the end of the day, resilience is security. Microsoft—like I said before—they accounted for 99.9% that they were less likely to be compromised with MFA. Google's auto-enrollments cut account takeovers by half. And it's a pattern that is repeated over and over again in the industry. If you remove friction and you bake security into the default path, you are making a more resilient workforce.You are making a workforce that will happily comply with your security controls and not look for ways to get around them. 'cause if you allow, if you, make it hard, they will route around it again, not maliciously. Because of the fact that they have reached that budget of compliance, they have reached that level of, I'm so freaking annoyed that I'm going to go around this.So reducing friction, lowering that off toil, you get faster responses. And I'm trying to bring this back to the incident management space, 'cause maybe I know my audience a little bit. fewer workarounds means fewer incidents. People are doing more and more workarounds of the security, they're going to cause more security incidents.There was one security incident guy in here. and frankly, a more confident workforce is a stronger culture for us to have within our organizations. The psychological safety will be better. There's gonna be better feedback loops. People, really like when you show that you care about annoying them.if you go to your, teams and talk about this and work with them to find better ways to make their lives just slightly better, like maybe one less off per like hour, you'd be surprised a level of happiness you'll generate within your workforces. So quick 90 day plan for you. A s your legacy MFA enable number matching MFA.So what I'm talking about here is getting rid of SMS as a second factor that is not secure. SMS is not secure. I don't know if anyone needs to hear that. I'll say it one more time. SMS is—say it with me—SMS is not secure. Thank you. It is incredibly easy to spoof a phone number and take over an account via that.Pilot passkeys to really build that internal muscle, and adopt or build helpers because sadly, there's not many out there that do this kind of thing that remove this copy-and-paste secret from your daily tools. This is really an easy way to get people moving in the right direction to lower the friction but also make your company more secure.And again, from a general sense, and this is goes back to why I just started the physician as productivity architect. Invest in friction reduction as a whole, not just on security, not just on anywhere else, but if, people are experiencing friction, they're going to be doing workarounds, they're going to be frustrated, they're going to feel like you don't care about their work.That is important. You have to make the secure path, the easiest path you really need to fund internal productivity, tooling and internal security tooling. 'cause at the end of the day, like these tools that every company has. Procreating all around their environments. Those are the problem apps that need to be talked about more frankly.incident.io has great UX engineers. They're gonna be focusing on that. All the SaaS products that you purchase have UX people that are doing great things. Your internal engineers—typically—they're not thinking about UX, they're coding for a purpose. But if you really invest in training and learning about UX within your internal teams,You'll see a lot better results and also measure and iterate as if productivity and friction is a product. Your people are a product giving them happiness is a product and it's something that you need to worry about. 'cause if you don't, again, like the results are clear. If people are frustrated, they're going to do the wrong thing.Whether or not it's meant in any sort of malice or not. So make them happy. Give them a little less frustration in their day. Do something that lowers the friction of their daily lives, of their daily work, and you'll be so surprised at the outcomes that you see. I see this every day, in, day out. The tools that I build that reduce friction, that make people happier, those are just having that smile on their face means that they're one less.Oh fuck. From just burning the place down. So thank you. That's it.San Francisco 2025 Sessions
The evolution of incident management
Martin Smith, Principal Architect, SRE, Nvidia
View session
From error to insight: Human factors in incidents
Molly Struve, Staff Site Reliability Engineer, Netflix
View session
Our data disappeared and (almost) nobody noticed: Incident lessons learned
Michael Tweed, Principal Software Engineer, Skyscanner
View session
Claude Code for SREs
Kushal Thakkar, Member of Technical Staff, Anthropic
View session
Boundary Cases: Technical and social challenges in cross-system debugging
Sara Hartse, Software Engineer, Render
View session
SEV me the trouble: Pre-incidents at Plaid
Derek Brown, Head of Security Engineering, Plaid
View session
Navigating disruption: Zendesk's migration journey to incident.io
Anna Roussanova, Engineering Manager, Zendesk
View session
What Real Housewives taught me about postmortems
Paige Cruz, Principal Developer Advocate, Chronosphere
View session
Security without speed bumps: Making the secure path the easy path
- Dennis Henry, Productivity Architect, Okta
View session