Auth on the web: better authentication

Has this ever happened to you?

Jessica says every time I log into work using 2FA, I get distracted by stuff on my phone and lose 20 minutes.

I want this something I have that doesn't do a thousand other things.

Last week I bought a YubiKey.

Brilliant.

It never shows me tweets.

We've been led to believe that this additional friction, this additional friction of authentication of going to get your phone, entering a code, that this makes things more secure.

And this is certainly true to an extent-it's why two factor authentication or 2FA is so effective.

You're adding additional checks to make sure people are who they say they are.

But I'm not sure if this graph is particularly accurate.

I have a theory that there are diminishing returns between the types of friction that you add, and the relationship between security and friction is not necessarily linear.

Maybe friction isn't even the answer.

If we can reframe friction as a series of controls or checks that doesn't put the owners on the end user.

Because our existing methods of authentication, this is most commonly passwords, this is a broken system.

They add friction and they aren't actually all that secure.

Google has committed to a passwordless future and in doing so they've committed to a more frictionless authentication future.

But Google has been promising this for like a decade.

So why is it taking so long to destroy passwords?

Why is it that we can't move to a better solution?

This is what we're going to explore today, how to improve web authentication and the challenges to achieving this goal.

My name is Kelly Robinson, and I am coming to you from Brooklyn, New York.

I've been working on the account security team at Twilio for a little over four years now.

I focus on developer experience and onboarding for authentication APIs, for things like phone verification and two factor authentication.

And as part of that, I spend a decent amount of my time researching new technology and best practices, but also working with our internal identity team to understand what's feasible.

All right.

Let's look at what we're going to cover today.

There are three main categories of authentication that I want to talk about, including biometrics, contextual data or background signals and using our devices as secure keys.

And then I'll wrap up with some recommendations and leave you with some resources to get started on your own.

I love this quote from the security researcher, Cormac Herley, who says it is mainly time and not money that users risk when attacked.

It's also time that security advice asks of them.

This is from 2009, so you could argue that there's a lot more money at stake today, but I think the sentiment holds true that a lot of security advice expects that users are going to take time to do things like setting up a password manager and enabling to 2FA, going to buy a YubiKey.

So when we talk about friction, we talk about requiring this additional time and effort from users.

It's what helps make it hard for bad actors to get access to something they shouldn't.

It's also what helps make it hard for bots and scripts to take advantage of something they shouldn't.

Friction isn't necessarily bad-users are accustomed to it to a certain extent, but remember, Jessica's tweet from the beginning-any amount of friction can prevent a user from achieving their goal, and that can be bad for business.

So when I talk about a frictionless options and frictionless options for better authentication, it's about, about decreasing the amount of time for the end user.

This might not equate to no time, but it definitely should be less.

An easy example of this is the difference between unlocking your phone with a pin versus using a fingerprint.

Yes.

You still have to touch the phone, but it's a much easier process.

And that brings us nicely to biometric authentication.

This category of frictionless authentication refers to something that you are or something that you do.

And when it, within that, there are two subtypes that I want to think about.

First is characteristics.

This is probably the most common.

Think your fingerprints, retina scans, face ID.

And then there's the behaviors.

This could be voice cadence, keystroke analysis, even the way that you walk could be used here.

We're probably all familiar with things like fingerprint or retina scanners, if nothing else, than from watching any heist movie, but a couple other examples of biometric authentication that get used behind the scenes include things like voice recognition.

This can be explicitly set up in some call centers and that's definitely where it's going to be more common.

But something that I wanted to call out here.

And then also keystroke analysis can be used to verify your identity and that can be done just from your typing behavior.

It's an interesting application of biometrics, even if it's more something that you do instead of something that you are.

Obviously all of the pros to all of these methods include that they reduce friction.

But other than that, biometric authentication also has some distinct advantages.

Things inherent to yourself, mean that it's something that you don't have to think about.

And it's also something that you generally can't lose.

It's also something that we think about being very secure, which means that people are going to be accustomed and think of this as a good method of authentication.

It also means that account recovery is less of a concern.

On the other hand, a lot of biometric authentication is specific to a device.

So while I can log into my bank with face ID on my phone, I can't do that on my computer.

And the reason for that is that Apple is storing your biometric data on the device.

And that's good because if you start to store that data on your server, you're going to put a target on your back.

Depending on how you collect and store the data, this also could mean less privacy for end users and the potential for bias in your algorithms.

One of the biggest categories of users for keystroke analysis are these remote proctoring services for remote testing.

And this is to make sure that students aren't cheating.

They're collecting and storing all of this information about users-biometric data, details, all this stuff about users, and that's going to lead to some privacy concerns.

And this is one example where to me, it seems like overkill to keep all of this information around, especially when you're dealing with minors.

And especially when you're dealing with people who probably don't have a choice about using these services.

And because artificial intelligence is only as good as the data that informs the models, we end up with this racism and bias in our speech recognition systems as documented in the New York Times.

There's also this assumption, one that I even made earlier, that biometrics won't change, but they can in this circumstance, a user's fingerprints changed from rock climbing, but these circumstances can happen in more common ways too, think about wearing gloves in the winter or, wearing a face mask on the train.

We noticed that these things had to be adjusted when we started all wearing masks during the Corona virus pandemic, because we hadn't had, didn't have access to our biometric data anymore.

Biometrics are still incredibly useful, as long as we build applications that use them responsibly`.

The next category I want to discuss is background signals.

This includes anything happening around us that might give the application an idea of whether or not we are who we say we are.

This includes data that might be provided by the device or application like geolocation, IP addresses, browser fingerprinting, that kind of thing.

Another category that I think is interesting or an example here is header enrichment, also known as silent authentication, another type of background signal where the carrier sends device information like your IMSI or your, IMEI to validate that you're using a trusted and known device.

I also put things like historical behavior in this category, you could probably argue that this belongs somewhere else, but the idea being that you could build a profile about a user's expected behavior and then use that to detect outliers.

I think the big benefit of this category is that it's relatively easy and cheap to implement some of these basic checks like geolocation.

The downside is that not only could you spoof things like a location, there are legitimate reasons that someone might be trying to access your location from outside their normal location.

You also need to do a decent amount of data engineering for any amount of complex analysis, which might affect the, whether or not this is a reasonable solution for you.

Contextual data is a especialky useful for triggering step up authentication, though I am seeing things like header enrichment being used to completely replace SMS based 2FA where it's available.

The last category I want to talk through is using our devices.

Things like our phones and computers as secure keys.

Under the hood, this uses public key cryptography generating a key pair on your device, and then sending the public key to the server for ongoing authentication.

The two main examples of this include webAuthn, which is an open standard that uses browser APIs, where the end user could use either a compatible phone, computer or a YubiKey.

And second push authentication, which is generally built into a specific mobile application, very similar to WebAuthn, but it's a proprietary solution.

Unlike background signals, this method can completely replace passwords.

This is what Google is using when they say they're getting rid of passwords.

It's especially good for this since it's very secure and phishing resistant.

This method also works really well when it uses the devices we already have, things like our phones and computers.

However, like biometrics, by nature this is per device.

And one thing that every company has to figure out is how to handle fall back on devices that aren't registered yet, or don't have support for this method.

This also makes things like account recovery a challenge, if you end up losing a device.

And finally, while things like browser support for WebAuthn are pretty ubiquitous, it's up to about 90%, which is really good, device support is not as advanced.

So when you look at authenticator options for WebAuthn, roaming authenticators, like YubiKeys are pretty expensive, $50 or more in US dollars.

And this might be okay if you're an IT department buying these in bulk for your employees, but most individuals probably aren't going to buy one of these themselves.

But platform authenticators, these are the things that are built into the devices we already have, this will be much easier to use and doesn't require anyone that has a complete security mindset.

Unfortunately, not every device is a platform authenticator.

I polled my probably tech savvy, Twitter followers, and up to 40% of them said that they didn't have a platform authenticator.

This category of frictionless authentication is one that I think will become really common eventually.

And that's why I think you should start building it now for users that can support it.

Like most security recommendations your mileage may vary based on your engineering team's capacity or the types of things that you're protecting.

But I think most of us can agree that less friction is a better user experience.

So let's recap some recommendations.

If you're implementing biometrics, try to do so in a way that means biometric data doesn't have to leave the device.

A lot of frictionless authentication means using data signals to make decisions, but that doesn't always mean that you need to store that data or store PII.

When you do detect outliers in your data, you're ultimately in control of how you want to leverage that information.

But one thing I see a lot of companies doing is using that as a way to trigger step up authentication.

So you can do the work behind the scenes.

And then if anything looks wrong, you can fall back to other methods that might introduce more friction if you're worried about it.

With that you should also offer device authentication for the users that can support it.

Again, just because not everyone can use it yet doesn't mean that you shouldn't still offer device authentication for the users that can use it.

This is going to be one way to delight security conscious users and ultimately decrease password usage with a more secure form of authentication.

And finally think about account recovery and all of this.

You'll need fallback options, whether that's because somebody is wearing a mask and face detection fails, or because they lose a device key.

Frictionless authentication is not a silver bullet, but it can improve the user experience and improve your conversion rates.

Of course, this is not an exhaustive list of options, so I'd love to hear from you about your experience building frictionless authentication, what's working for you, what have you tried that doesn't work?

Are there any tools that you wish existed for this?

You can find all of these slides by going to this URL, which also includes a bunch of links to resources for further reading at the end.

You can also find me on twitter @kellyrobinson or send me an email [email protected].

I hope I've given you some inspiration for how to build better authentication on the web.

Let me know if you have any questions or ideas.

Once again, my name is Kelly Robinson and thank you for listening.