Auth on the web: better experiences

What's up everyone.

My name is Phil Nash and I am a developer evangelist for Twilio.

Twilio is a communications and customer engagement platform.

That means we have a whole bunch of APIs that you can use in your applications to connect people with voice, video, messaging, and email, and you know, for the security conscious build account security flows, in particular phone number verification and two factor authentication.

Now I'm not here to talk about Twilio day, but if you do ever want to talk to me about that, you can always find me online all over the place at, @philnash, or just drop me an email.

[email protected].

What we are here or what I am here to talk to you about is creating better authentication experiences.

Now it would be lovely if we didn't necessarily have to talk about this.

It'd be lovely if we could use all the fancy, frictionless authentication messages that my colleague Kelly Robinson is here at Safe to talk about.

And you should, you know, we need that to gain in popularity and understanding amongst our users.

But we are developing in the real world with real users and existing applications.

And those real users have spent their entire lives putting the, you know, the same password, username and password to every site and application, because it is easier to remember that way.

There was a survey in 2018, in which 65% of people admitted to password reuse either some of the time or all of the time.

And I still wonder how many of the people who said they always use different passwords, whether they were lying.

You know, if you asked me if I reuse passwords, I would say no.

Even if I did, I'd just feel guilty about it.

So password reuse is happening all over the place.

And then that same survey found that only 24% of respondents use a password manager.

Which means at my best guess, some of those 35% of people that said they use a different password for every site is made up of a good portion of people who are either also lying or have incredible memories or only ever log into their email , their bank and Facebook.

So only have three different passwords to remember.

And that one last one seems somewhat unlikely to me.

So we've spent time trying to fix this by including increasingly obscure restrictions on passwords and it just leads to everyone reusing one somewhat complicated password that they are sure is absolutely secure.

Probably looks at little bit like this.

And you know, that fits pretty much every single one of those password requirements that you always see on websites.

So we've not been doing the best of jobs there.

And indeed, we have all the other applications out there in the world to blame for then leaking those usernames and passwords on a daily basis.

HaveIbeen pwned.com is a, is a collection of those breaches that are just that are leaks of data out into the world.

And and it gives attackers whole numbers of datasets of user names and passwords that they can use to attack your applications, your accounts you know, it's almost hard not to try to break into accounts with the amount of data that is available on people and their usernames and passwords.

And so.

This leads us to our current saviour-two factor authentication.

Two factor authentication means that a user provides, both something they know, which is that password.

And the thing that they kind of understand already, and then something they have something like a device or a phone number of physical token of some sort.

And providing both at login, we have a better chance of deeming them the correct user.

who's allowed to log into this account.

Hopefully two factor authentication is fairly well understood and I believe, you know, it's also something that people know how to use.

SMS then is the most popular method of two factor authentication.

It's also the least secure method of two factor authentication, but like, let's not let that put us off.

We need to consider just a few things here.

You know, most people in the world can receive an SMS message.

SMS two factor authentication works.

The success rate is, is good.

And two factor authentication itself as a, as an idea only works if people use it.

And if people decide to only use that password, then they are still leaving themselves vulnerable.

However if they, if they add a 2 factor authentication of some sort, even if it is SMS it becomes better than that password.

And so users understand SMS two factor authentication, and it comes with the least amount of friction to kind of set up for most people.

So SMS 2 factor authentication is not going away.

It's a vital aid to help users protect their accounts in a way that they understand and can easily sign up for.

People understand it, it works.

It's not going away.

However, there may be some issues with it still.

In the front end, there have been countless studies on how degraded performance in a website leads to a drop in page use and conversions and degraded performance of like the, the ideas of tenths of seconds can change things.

And yet now I am here telling you that sending two factor authentication over an SMS is a great idea.

Literally sending a user from the web browser to a different app, to try to remember a code and return to the browser, to enter it into a form indeed building in the wait for that SMS to arrive at their device.

And then, you know, if the user's on a desktop, you 've got to send them to open a completely different device, to copy a code across from it.

And I can't tell you the number of times I've reached for my phone to get a two factor authentication code and just found myself checking Twitter on my phone instead.

It's a bad experience.

It's all friction.

And we know intuitively that this friction leads to poor experiences and greater drop-off when people are using our applications.

So what can we do to reduce this friction?

Well ideally we could verify that that user received the SMS message with the correct code in it, without making the user leave the browser, look at another device.

And thankfully this is possible today.

And that's, that's what the rest of this talk is about.

The rest of thistalk we're going to see how we can reduce the friction in a two factor authentication experience over SMS with the use of a couple of web technologies that you may or may not know about.

First up-and I think the simplicity of this is the best thing-it's the auto-complete attribute.

It is simple, but on iOS, it is effective in reducing the friction of entering SMS two factor authentication codes in Safari.

So let's see what I mean by this.

Auto complete is an attribute on the input element.

And it can take many values.

It's used to specify what, if any permission, a user agent has to automatically fill in a form field along with guidance as to what that field should be filled with.

Now, for our purposes today, the value we're looking at is one-time-code.

And on iOS, when an input element has the autocomplete attribute set to a one-time-code and the device receives an SMS message with what looks like a one time password and Safari will extract the code from the SMS and show it as the keyboard autocomplete.

The user doesn't have to flip to the messages app.

They don't have to memorize the code.

You know, you can't just copy a piece of text for an SMS of course, and then type it in there, just press the button and it's done.

It looks a little bit like this, you know, when you, when you hit your login and you hand on to your two factor authentication flow.

The message comes through and it's already populated in that keyboard hitting the hitting the central button then submits it to the form and you move on.

Frictionless.

I love it because you don't have to flip across to any other application.

You just get to press the button and move on into the into the next stage of your login.

It's brilliant.

So autocomplete, I mean, autocomplete has more than we were just talking about here.

You know, it can also be used for things like addresses, names, credit card data, contact data.

But what, and while we're on the top of logging into accounts, I do want to point out some other useful values.

So autocomplete can also take the value of email or username, which are useful if the email address is the username or you have a separate username and need the browser to understand that.

And for passwords, you can also use the values new-password and current-password some passwords will use the new password value to then suggest a generated password for your user.

Like this example in Firefox this is also a hope that they will then choose to use that password, and not the same as every other one they're already using every other site.

They're also good...these are also good hints to browsers and password managers.

For what to fill in when logging in or indeed updating a password you know, when you have enter your old password and your new password again, then using current-password, and new-password means that browseers won't try and fill in the same password to all three things, for example.

And then before we move on from the humble input element, I just want to talk about one other little thing that can make filling in one-time passwords easier, particularly on mobile devices across the board.

Set the input mode correctly.

When you a two-factor authentication code should be input.

Should be of type text and that's fine, but a normal kind of type text gives you this text keyboard on at least on iOS and that's not super useful for the user.

They have to hit the numbers, the number keyboard, and then start typing it in.

And even then they only have the small numbers to deal with.

Now the answer to this is not to set the input type to number.

Two factor authentication code may well be a set of digits, but it's not actually a number and the number type of input, I find acts weirdly at times as well.

What you need to do is set the inputmode and this case to numeric.

And when you do that the number pad keyboard will come up and make it much easier to type.

It looks like this.

So use inputmode, your mobile users if you have to type in something, will be happier.

Cool.

So using autocomplete works on Safari on iOS.

But you are actually in luck.

If your user is a deep into the Apple ecosystem, then this may also work for them on desktop with no further work on your part.

If you user has their messages connected to their, their Mac and they use Safari on the desktop, then this will allow them to autocomplete their one-time password as well.

And so this is the example of coming from Safari.

On the Mac and when you log in the text is going to your phone, but you can still fill it in on the using that default using that ... suggestion.

Okay.

Cool.

So the autocomplete attribute with one-time-code will give us this behavior in iOS and Safari, and it is a wonderful, progressive enhancement.

It's a single attributes that we can add to an input element and it just works.

What about other browsers?

Well, we that is not the behavior.

You can still use the auto-complete attribute on other browsers.

In fact, you should like I said, it's an enhancement, but it's not going to get this behavior.

And in this case, we have to turn to the relatively new API, the WebOTP API.

WebOTP API.

allows you, as a developer to make a request to the browser, to retrieve a credential, in this case an OTP code.

And now while WebOTP is its own proposal, it's actually implemented as part of the credential management API.

That's the API that's used to store and retrieve passwords in the browsers, password manager and public private key pairs that are then used in the web authentication API.

The WebOTP side of this allows us to request from the browser a one-time code from an SMS transport.

And we'll see the code for that in a minute.

So how do you use it?

Well, the implementation actually implementation actually starts with the OTP message you send in order to tie a message and the code to the website, messages need to be sent in a specific format.

The message must take the format of a, of the human readable message first followed by on the last line of the message and @ symbol followed by the domain of the site that you're on and a space, a hash symbol, and that one-time password code.

That allows the browser to not only understand that this is a one-time code, but that it is tied to the website that we're on increasing, I guess, the security there.

So next, when you know that you've sent this one time code in this correct format, and you're displaying a form to the user to submit it, you can now make the request to the credentials API to retrieve the one-time password from the message.

Since you know, we're in JavaScript now and this is another progressive enhancement we want to feature detect whether this is possible first by checking for OTP credential, being in the in the window namespace.

And then if it is the case, you can use navigator.credentials .get to make that request to the credentials and specifying that the OTP transport should be SMS.

This triggers a browser's permissions dialogue, and when they usergives permission and the text as appeared in the messages application will return an object, which includes the code.

So you can use that code to auto fill into the form for the user, auto submit the form and, and again, move them on throughout their authentication process.

No switching apps, just a quick permissions dialogue and you're logged in.

And it looks like this.

So again, you hit login send the message and in the background, you see the messages has appeared but also there's that permissions dialogue that pops up and moves you on in.

So, this actually works in Chrome on Android, and that's where I've tested it as well as according to MDN, both Opera and Samsung Internet on Android.

You might now be wondering about desktop browsers.

Since Chrome version 93, the desktop browser also supports requesting an OTP credential however much like in the Apple version of this, you need to be using matching browsers.

In this case, you need to be signed into your Chrome browser on the desktop, as well as the mobile device.

And the browser is then able to make the request and receive the message from the mobile device.

Now, I did want to get an example of that to show you in this in this talk, but Chrome is not normally my native browser, Android is not normally my phone of choice.

And therefore I I was unable to make them believe that they should help each other out.

But using this code using it with feature detection to make sure it only works in browser that supports it gives you that option, that opportunity for it to work and be able to act the same as on mobile as well.

So, we can hopefully on desktop browsers also remove some of this friction from this process.

I currently ... the WebOTP API has been spec'd and implemented for SMS based one-time passwords.

But thankfully the spec actually leaves space open for an alternative for alternative delivery methods for that one-time password.

Like I would love to see an integration with my authenticator app I use the Authy application for this and I'd love to be able to make a request to the operating system, to then pick your default authenticator app tied together with the URL and, and some of the part of that within the authenticator app, and allowing me, allow me to both use my authenticator app, which is more secure than SMS without having to constantly get my phone out.

Now, this is more difficult I imagine.

There isn't, as far as I'm aware, any standard available between browsers and authenticator apps via the operating system.

But you know, for the most part there isn't really that with SMS either it just happens that this API has been built kind of as a one-off for now.

However, that's the beauty of the spec being open for that interpretation and ability to build for other flows, other devices.

So, I mean, right, you can actually build an Android application with permission, give it permission to intercept, to read SMS messages.

You can't do that in the same account, you can't do that on iOS, and it almost doesn't make sense on desktop since SMS is a, is a mobile device kind of based thing.

So, WebOTP is for SMS is kind of a curiosity right now that in my mind almost shouldn't work.

But if this kind of ad hoc SMS interception can evolve into a proper interface on the operating system, then presumably the same could happen for authenticator apps.

And we can improve this process for more more users.

So, SMS two factor authentication is not going away.

It's convenient for users.

It works and it is more secure than just a password.

Hopefully we agree on those things.

And so we can turn to the experience instead, and with a couple of attributes on the HTML input, we can hint to the browser, thatthat input element is for a one-time code and Safari will do that job to autofill that with an incoming message.

And with a little bit more code and honestly I, I didn't show much earlier, but a full implementation does not take a lot more code than that.

We can achieve similar results on Android using this WebOTP API, and piggybacking upon that credentials management system.

If you're using the right combination of browsers and operating systems, this does even stretch to the desktop.

Even if I couldn't make that work myself on Chrome, it did work for me on Safari at least.

Overall, I love this.

It's typical, progressive, it's a typical web progressive enhancement.

If your browser or combination of devices doesn't support the API, then the user goes through the regular flow that we actually all understand already.

They do have to change their app.

They have to get their phone out to sign in, but we hope that they tolerate that for the extra security.

But if they're using a browser that supports these enhancements, then we can reduce or remove some of this friction from the process.

Your users can know that they are signing...they are more secure signing into their account, and it didn't take a lot more effort than just using that single factor.

And overall, I love how the web is adapting here.

First, we have a traditional method of two-factor authentication that we can enhance the experience for, and the web is also pushing these new alternatives for authentication that improves security and experience at the same time.

Maybe we'll never rid ourselves of the password or of the SMS one-time password completely, but we can share as anything, build a better experience with them.

And I look forward to smoother signing experiences, signing on experiences, from here on out.

Thanks again for joining me.

Again my name's Phil Nash, I'm a developer evangelist for Twilio and I can't wait to see the secure experiences that you build in your applications.

Thanks very much.