In the second episode of our Cyber Resilience Vlog Series, Axiad’s Vice President of Technology and Partnership Strategy, Karen Larson, discusses with Microsoft’s Tim Cappalli the topic of standards and how they can help increase security through phishing-resistant authentication. You can see the full video here and a partial transcription of the episode below.

Please stay tuned for future episodes, as we’ll be talking to different experts in the identity and security space about practical applications for different methods that you should be on the lookout for as a security practitioner.

Introduction

Karen Larson: Would you like to talk a about what’s happening in the standard space and provide background on why phishing is such a big and important problem?

Tim Cappalli: Absolutely. The reality is that most users are still signing in on the web with some form of phishing credential. I think everyone assumes it’s faster, but it’s not. The SMS one time password (OTP) is phishable, especially now that it automatically travels between your devices and through some copy and paste thing that arguably could be phished. Even app-based push can be phished.

When we talk about phishing resistance, I think the two most important properties are proximity from the authenticator and the place you’re trying to access from. So, what does proximity mean? My laptop is obviously proximate to itself, and my phone can be nearby to prove that it’s my laptop, but you also need the ability for the credential you’re using to be bound to the site you’re accessing. None of this exists today. Apple did some awesome work to try to make SMS OTPs a little better by adding the ability to declare in the SMS that this is only for specific origins and that has really helped. But at its core, you can only do so much, and this remains a topic that’s always vying for the top security issue.

Credential Misuse and Phishing

KL: It’s at the top of the Verizon report – credential misuse and phishing, so it’s right at the top of most people’s security list.

TC: These are all things no one actually likes. No one likes using an SMS OTP. No one likes using passwords. Everyone hates passwords. The idea of even asking people to have good password hygiene makes them freak out, so these are the realities of both consumer and enterprise problems. I think my favorite saying (and I don’t remember if I came up with it or stole it from someone else), but every enterprise or work user is just a consumer at work.  They’re going to have a consumer posture when they’re at work, no matter what you shoved down their throat in terms of doing XYZ. That just frustrates them, so that’s the age-old consumerization of IT.

KL: I remember at my first job we were building a website, and it was when websites were new and nobody really knew what they were doing. I was talking with our marketing manager, and she asked me, “How do we know that people are really who they say they are online?” And I said “Well, that’s a deep question.” And here we are 15-20 years later, still trying to figure out how to tie physical presence with the digital presence online and assure that you are who you say you are.

TC: I think the important point of all this is for consumers, it’s their own data at risk. For the enterprise, a lot of other people’s data is at risk and then that’s problematic. Then in the middle you have this regulated consumer where the bank or some other entity is liable for a fraudulent transaction. It’s a very interesting spectrum and reminds me of when I worked at a college. One of our security advisers wanted to make students jump through all these hoops to sign into something and it made their experience miserable. You’re just asking for people to evolve to meet perfect security standards and it’s too much. We see that today for all sorts of use cases.

Modernizing Standards

KL: I think that’s where some of the standards work that you’ve been doing comes in. When you look at things like digital wallets and verifiable credentials, digital identity and coupling that with things like passkeys from FIDO, I think that provides a very usable format for most people to be able to protect themselves and their identities online.

TC: Absolutely. The funny thing is that I think a lot of these standards predate me. I came in and kind of helped enhance them. I didn’t create them, and they were in good shape. A lot of the challenges with any type of standard is you must make sure the right players are at the table to implement them.

The FIDO work started around 2014 officially and it didn’t have all three big tech players at the table until 2019. Until then, you just had very different experiences, browsers did different things like different operating systems, and you ended up with a mess of a matrix of green and red that’s just not it’s not feasible. It’s not good for users and it’s not good for convincing leadership that you should deploy this. I think the standards have been much better now that we have everyone to the table.

I think what happened over the past three years that led us to passkeys is we answered the question, “What optimizations both in the specs and then the implementations can we make to actually make this usable for mass market?” I think it was always this FIDO pipe dream (and I’m sorry if that insults anyone) that everyone in the world was going to have a security key and I think that would be great. But they’re just not. A good example is my parents or even my non-technical friends – there’s absolutely no way you can get them to use it.

KL: I always think of standards as being that leading edge of how we would ideally like to see the technology work. Given that there’s no real driver for people to say, “Adopt a whole standard,” what do you see as being the most important developments that are coming out of the standards bodies right now for security practitioners around authentication? And then, how do you see those standards being adopted so that people can use them on a daily basis?

TC: I think the current status is 3-4 years for passkeys. It is getting over to a phishing-resistant default credential for the web, which is kind of the way I think about it. There’s obviously nuances in there, like if you are a high security environment that was using certified security keys before, succinct passkeys are probably not right for you and that’s OK. I think early on we had to come to terms with that.

The challenge is the interoperability and how it hits the mass market. It’s kind of in that same bucket as FIDO was a few years ago. How do we actually make some of these standards? There’s a lot more standards in that space than there are for FIDO. FIDO is only two standards and even that could be complicated, so trying to bring all these different groups together is tough. ‘

Standards organizations (and I hate to use the word cliques) are just groups of people that work on certain problems, and it ends up being cliquey because everyone in that circle understands what they’re trying to do. Usually, it’s tied to one standards body. Getting these cliques to come together at the table in the lunchroom is kind of what’s been happening under the guise of “How do we make this work?”

There’s a lot of proprietary implementations that work, but our responsibility is to create standards that are appealing to a mass audience. This is why FIDO and passkeys are catching on – they serve one purpose – to authenticate a user.

Conclusion

KL: If you could give security practitioners one piece of advice in terms of implementing standards, what would it be and why?

TC: I think we’re at the point where we probably need to start the phrase “don’t roll your own FIDO.” We have “Don’t roll your own crypto” as an age-old saying. I think we’re at that same point with FIDO and there’s a lot of awesome libraries out there that have been updated for passkeys. You could get passkeys up and running on your service probably in about a half hour with Matt Miller’s library. He has both the server side and the front-end library.

I think we’re getting to that point where there are some complexities with these protocols, but we’ve tried to abstract away a lot of that. The reality is these libraries and SDKs will help greatly. It will help people keep up with the standards. I think one of the problems across all standards is the visibility into the changes.

One example of something we’ve done with passkeys is passkeys.dev. We’ve never really had true, neutral generic developer guidance for the average person who’s never seen FIDO before. In this area, we have the people who have been in FIDO almost too long. I understand that people have been invested in the long term and then you have the people that may say “I’ve never heard of FIDO passkey, but I have no clue what it means.”

In my opinion, you shouldn’t have to know any of these details unless you want to. You should be able to roll this out in an easy manner. If you want to implement it yourself in terms of your own authentication system, you should use a library and SDK. But also, if you are using an identity as a service provider, make sure you’re pressing on them to support this because they should be able to take a lot of that complexity away for you.

I think trying to follow all these standards and all the updates and all the changes, especially across clients, is extremely difficult. For example, browsers update every week, operating systems update quarterly typically, so trying to track all that as an individual organization and trying to implement is really tough. So, take advantage of those resources that are out there.

You can watch the full video here.