What's new with sign up and sign in on the web (Google I/O '18)

Just another WordPress site

What's new with sign up and sign in on the web (Google I/O '18)

[MUSIC PLAYING] EIJI KITAMURA: So today’s session is about what’s new with sign-up and sign-in on the web Are you enjoying Google I/O so far? We only have– yeah? [APPLAUSE] We only have a few hours left for the rest of Google I/O, but I’m pretty sure you’ll be excited to learn new things from this session OK, I need to have this clicker So let me start with this question for you What makes good sign-up and sign-in? We consider there are three principles First, good security Sign-in is the most important gatekeeper for a website to protect users’ information from abusive behaviors and attackers Building a website with a vulnerable sign-in mechanism means giving attackers a chance to abuse your website And in the worst case, it critically damages your business So building your website with first class security is quite important But that doesn’t mean that you can sacrifice user experience In many cases, adding better security creates more obstacles and brings more friction for your users to enter your website Thinking about user first web experience, you should make sure logging into your website is as seamless as possible, while having good security And finally, good sign-up and sign-in are often overlooked as a critical part of userflow Developers tend to be more excited about new ideas and innovative features, and pay less attention to making their sign-up and sign-in secure and low friction That’s why it’s important that building them is easy enough and low cost With that in mind, today, we will cover three topics– one tap sign-up up and auto sign-in, reCAPTCHA v3, and web authentication Let’s get started Implementing sign-up and sign-in securely using username and password is challenging I’m not saying that it’s technically impossible, but the user’s safety heavily relies on how they create their own passwords Their passwords could be weak, forgotten, reused, or stolen Balázs is going to explain more about these challenges later in the session But this is why we’ve been recommending identity federation for many years Identity federation is a way for users to sign-up or sign-in using an account hosted on a third party website, which is called the identity provider Identity federation is usually built upon standards of code such as OpenID Connect or OWS With identity federation, users do not need to create additional passwords You can delegate security challenges to a identity provider, and you can receive profile information from that identity provider And as many of you know, Google is one of such identity providers You can already take advantage of Google’s sign-in button to enable identity federation on your website And at Google I/O last year, I briefly talked about a JavaScript library that makes sign-up easier And at Chrome Dev Summit last year, we officially announced it as One Tap Sign-Up and Auto Sign-In It’s a new user experience for identity federation with Google that allows users to sign up with just one touch We have a number of partners already on board or implementing with this library, and they’re producing amazing results Let me briefly talk about a few of them Redfin, a real estate company in the US, saw an 80% increase in sign-ups after implementing One Tap Sign-Up Also, over 40% of these new users returned to their website more than five times after signing up Trivago is one of the world’s leading hotel search engines,

operating in 55 countries It gained 50% more new sign-ups with twice as many sign-in users after implementing this library Cifroclub, Letras, and Palco, popular music sites in Brazil for chorus, lyrics and songs, got 43 times more users signing up after integrating One Tap Sign-Up This is not a typo I said 43 times, which means 4,300% more users That’s an incredible number And user engagement, such as favoring artists, creating playlists or commenting, liking, chords, has also increased almost 50% per user This is impressive So here’s how it works The user opens the sign-up page, selects one of the Google accounts, and they are signed up It’s just that It takes less than 10 seconds The animation on the slide might be too quick to catch up what’s going on, but it’s actually that easy One Tap Sign-Up is revolutionary because, on top of those benefits that I have briefly mentioned earlier in this session for identity federation in general, it’s completely passwordless and requires only one tap for users to sign up No email verification is required Think about it You have to open up email client, find the right email, and clicking a link in that email It’s kind of a hassle, right? You can completely eliminate that step from the user It’s a big deal And third, it works across all modern browsers Using this API is quite simple Start with loading this JavaScript library Once it’s loaded, show a sign-up [? label ?] by calling this method, googleyolo.hint, and it will show an account chooser You need to create a client ID at Google Developer Console in advance Note that since this is a powerful API, we are reviewing sites that are making use of this library Once a user taps on one of the accounts, the promise will resolve, and you will receive a result that contains an ID token Use the ID token to verify the user’s identity on your server If you already have a Google sign-in back-end, you can reuse it Once the ID token’s verified, extract the user’s profile information and establish a new session And the user is signed up As a bonus, when the user session expires, or the user lands on your website from a different device, you can let the user sign back in automatically To perform auto sign-in, just call googleyolo.retrieve to obtain the user’s ID token Then you can use that ID token to let the user sign back in and resume that session By the way, you might have heard about a API called the Credential Management API It’s an open web API to handle credentials using JavaScript Now, One-Tap library actually uses this Credential Management API behind the scenes if the browser supports it and there is a stored password for the website If you want to retrieve an existing password, add googleyolo id-and-password It will give you a username and password instead of an ID token so you can use that information to authenticate the user When a user clicks the sign-out button, the user probably wants to keep signed out In that case, call googleyolo.disableAutoSignIn That way, googleyolo.retrieve will stop returning the ID token until the user explicitly signs back in So that’s the One Tap Sign-Up Let me recap One Tap Sign-Up is secure because it’s Google’s identity federation It provides a great user experience for a user to sign up with just one tap and auto sign-in It’s easy to implement with simple APIs To learn more about One Tap Sign-Up, please visit developers.google.com/identity and you’ll find more detailed documentation OK, so far, I’ve been talking about identity federation

But I guess that many of you might be interested in some solutions about when you are using a username and password Earlier in this session, I talked about challenges with passwords What can you do if an attacker already knows your user’s password and tries to hijack account? And in many cases, account hijacking is done by bots This means if you could filter out bots, the number of account hijacks should decrease And that’s what reCAPTCHA does Six years ago, it asked users to read a distorted text like this, but we knew we could do better We then developed reCAPTCHA v2, where users can simply tap a checkbox to verify v2 is smart enough to determine if an interaction is abusive just with that simple gesture And if reCAPTCHA is still uncertain, it asks an additional challenge like select all images with a street sign This is an example This is an example question many bots can not answer easily And we are protecting over 2 million websites every week from spam and abuse But bots evolve also The attacks against reCAPTCHA over the last few years, last several years, have evolved from brute force or random guess bots to smarter and even AI guess bots They began to bring machine learning solutions and abusive humans to try to break these challenges and attack websites But we want to stop bots whether or not they can find the street signs in a set of images Today, we are announcing the public beta of reCAPTCHA v3 This new version comes with three new things at the high-level First, it requires no interactive challenges Two, it scores traffic with the Adaptive Risk Analysis Engine And third, it breaks down your traffic by action Let me walk you through each one In v3, reCAPTCHA detects whether an interaction with a website is abusive without even a single tap This means you can keep your website safe without interrupting any users And instead of a simple yes or no answer, it will give you a score which ranges from 0 to 1.0 The score is calculated by the reCAPTCHA Adaptive Risk Analysis Engine and the signals from interactions with your website Based on the score, you can define your own threshold to determine whether you should do further verification on the request Let’s say you get a login request with a very low score of 0.2 In that case, for example, you can request an additional authentication factor such as email verification, or send an email to an admin to ask for moderation, or throttle search requests from bots as a protection from scraping To use reCAPTCHA, first load the dev script library When the user submits a form, request a reCAPTCHA token And finally, submit the form along with the obtained token One nice thing about v3 is that it enables you to put it into almost all parts of your website, not only the sign-up page, but also many other places For example, from home page, to reading posts, logins, adding comments, and searches Wherever your website has potentially risky actions, you can protect with reCAPTCHA To do so, you can define a tag for each action Actions will also become a signal into the Adaptive Risk Analysis Engine As a result, you can treat scores differently depending on the actions Also, you can see the traffic breakdown and score distribution per action in the reCAPTCHA admin console So that’s reCAPTCHA v3 Let me recap reCAPTCHA v3 makes your website more secure by stopping bots

It doesn’t require user gesture by eliminating challenges, so there’s zero friction It gives you the flexibility as to how you want to treat suspicious traffic To learn more about reCAPTCHA v3, please visit g.co/recaptcha/v3io OK, I’ve been talking about two large features from Google, but I’d like to make a transition to talk about open web API, the Credential Management API I briefly talked about it earlier in the session As I said, One Tap Sign-Up contains Credential Management API But as it focuses on identity federation with Google, if you choose to use other identity options such as username and password, you should use Credential Management API We have already covered this topic at Google I/O last year, so let me quickly recap It’s an open web API that allows you to handle credentials using JavaScript With this API, you can enable things like auto sign-in or sign-in with browser’s native account chooser It can handle two different types of credentials– password credential and federated credential And now, we have a new type of credential being added to this API, which is called PublicKey credential With that, let me invite Balázs to talk about web authentication BALÁZS ENGEDY: Thank you, Eiji [APPLAUSE] Hi, everyone I’m Balázs I’m a software engineer on the Chrome Web Identity team And Eiji already mentioned that passwords create a number of issues I would like to talk a little bit more about two of them in particular The first one is password reuse, when your users are using the same password on multiple different websites And the second one is phishing, when attackers trick your users into entering their credentials into fake websites Historically, these issues have been really hard for developers to address because they both have to do with your users being only human So suppose one of your users– let’s call her Jane Doe– has accounts on 50 different websites What do you think? On how many other websites is Jane using the same password that she is using on your site? To answer that question, we’ve calculated some statistics client-side among Chrome password manager users And if Jane is anything like them, she would be using that password on 10 different web sites That’s 20% of all her accounts What does that mean? It means that if Jane’s password is compromised on any one of those 10 websites, it’s compromised on all of them, including yours So how often does this happen? According to another study, during a period of just one year, data breaches exposed a total of 1.9 billion usernames and passwords So this means that even if you have implemented all the password management best practices– for instance, you serve your login page, and preferably, your entire website over https, you never store or log plaintext passwords, you always hash passwords, and maybe you do even more– you’re still not done So suppose you’re using two-factor authentication To log in, Jane has to enter her password plus an OTP, a One-Time Password, for instance, a six-digit number that she receives to her phone Surely Jane is safe now, right? Well, unfortunately, OTPs are phished just as easily as passwords Let me show you what happens As soon as Jane enters her password into the phishing page, the attacker connects to the real website and initiates a login flow using the freshly stolen password The real website asks the attacker for the OTP The attacker, in turn, asks Jane In the meantime, the six-digit number is sent over SMS to Jane’s phone Jane is under the impression that she’s logging in to the real website, so she expects that she gets asked for the One-Time Password So as soon as it arrives, she enters it into the phishing page The attacker now simply forwards the OTP to the real website

And with that, they just gained access to Jane’s account Similar attacks are possible if Jane is using time-based OTPs generated by an app on her phone, or a hardware token, or if to sign in, Jane has to confirm that login attempt on her mobile device The problem is that, in all of these cases, we rely on Jane, a human, to recognize when she is not on the real website, but on a phishing page Remember the study from before? It also estimates that around 12.4 million users fell victim to phishing during the same one-year period This is why, last year at I/O, we recommended using security keys instead Many of you are familiar with the U2F universal second factor security keys that look like this Some of you may even be using them for two-factor verification already They main advantage of security keys over OTPs is that they cannot be fooled by phishing Security keys talk directly to the browser They can easily verify that URL of the page that Jane is visiting is the legitimate URL and not a slightly different URL corresponding to a phishing site So this removes the human error factor It is no longer Jane’s burden to verify the URL But if security keys are so awesome, how come we aren’t all using them on every website already today? Unfortunately, a key piece of the puzzle had been missing Previously, there hadn’t been a good way to access security keys on the web Some of you are already familiar with the U2F JavaScript API, which was a great first step But it also had a number of limitations For instance, it wasn’t available across all browsers And this is why I am super excited about the Web Authentication API, which is a brand new web platform API that provides a standardized way for using strong authentication on the web The new API is coming to major browsers and will be available on both mobile and desktop platforms And in fact, I’m delighted to announce that you can already try out the initial feature set with the latest Chrome beta So let’s see what makes this API so great First, it’s backwards compatible with existing U2F security keys The very same key that you registered through the U2F API can now be used through the Web Authentication API That means that you can migrate your site from U2F to WebAuthn without any user visible changes But WebAuthn is much more than just a new API WebAuthn also enables authenticators that come in a wide variety of form factors much more exciting than USB hardware tokens So if hardware tokens are not your cup of tea, don’t fall asleep just yet WebAuthn also brings many new features that enable exciting new use cases The single most important feature is probably that authenticators can now perform user verification This means that the authenticator can locally verify the user If Jane drops her authenticator on the street, you cannot just pick it up and use it It only responds to Jane User verification can take many forms It can be done using biometrics, such as a fingerprint scan, or an easy-to-remember PIN code And we are not only talking about external hardware tokens With WebAuthn, the built-in fingerprint reader in your notebook or phone can also become a user verifying authenticator Regardless of form factor, what makes user verifying authenticators so interesting is that they do not need to be combined with passwords to implement two-factor authentication There is already something that you have and something that you are, so you get great security And you also get a great user experience You no longer have to type your password, which is especially frustrating on mobile devices So let me show you what I’m talking about Can I switch to the demo device, please? Suppose that I’m browsing the web and I find something I want to buy I have with me here a Pixel 2 phone with a fingerprint sensor So suppose I have this camera cleaning kit that’s really nice and that’s a really good deal for just $0.10 So I add it to my cart Then I go to check out And then I choose to complete my checkout at Paypal

I get redirected to Paypal And because Paypal supports the Web Authentication API, I can easily verify my identity using just my fingerprint Select a credit card, shipping address, and I get redirected back to the merchant And there, my order is confirmed So I didn’t have to type a password and it was still secure And it was so much better a user experience Back to the slides, please So how does it all work? First, let’s take a look at how authenticators work in the first place All WebAuthn authenticators use public key cryptography There is a one-time set-up flow during which the user registers an authenticator with an account During registration, the authenticator generates a new public-private key pair The private key is stored locally and cannot be extracted from the authenticator The public key is sent to the server Then every time the user wants to authenticate, they have to prove to the website that they possess the private key This is done through the challenge-response-based protocol The web server sends a challenge to the authenticator, which in turn uses the private key to provide a cryptographic signature for this challenge The signature it sends to the web server, which verifies it against the public key and the challenge With user verifying authenticators, releasing the signature is also gated on successful user verification such as a fingerprint scan So your fingerprint never leaves the device It’s only used to locally unlock the authenticator Now let me walk you through the one-time set-up flow in more detail You did not see this in the demo because I already did this last week There are three important participants in this flow– the authenticator itself, the web application running in the browser, and the web server Suppose that it is once again Jane who is now setting up the fingerprint reader in her phone as an authenticator To kickoff the registration flow, the server first generates a challenge, a large random number that will be only used for the registration process and thrown away later The server stores this challenge in association with the user account and transmits it, along with user information, to the web app running in the browser The web app then calls the web authentication API This is what it looks like in code As Eiji mentioned, WebAuthn extends the Credential Management API so it’s available under navigator.credentials To create a new public key credential, you call create with the publicKey option You specify the challenge you received from the server, user information that will be displayed on the authenticator if it has a display, and the crypto algorithms that you wish to use In addition to these parameters that you just specified, the browser also extracts the authoritative domain name of the calling web application Then all this information is sent to the authenticator, which asks for user consent This is required so that malicious websites cannot use the API to track the user This protects the user’s privacy Once user consent is given, the authenticator generates a new public-private key pair It stores the private key internally, along with the credential ID, user information, and importantly, the domain name this credential belongs to Then the API call is resolved with the public key credential, which contains the unique identifier, the public key, and the signature key I created over the challenge, the domain name, the public key, the credential ID, and some other parameters The web app then forwards these values to the server There, you need to validate the signature And there’s a last step If the signature checks out, the server has to store the credential ID and the public key in association with the user account And don’t forget to invalidate the challenge It’s only valid for one transaction This concludes the registration flow

And remember, you only have to do this once Now, let’s take a closer look at how Jane can use the authenticator to log in without the password the next time The starting state here is that the authenticator already has a private key and the server has a corresponding public key in association with Jane’s account Remember that authentication is performed using a challenge-response based protocol that Jane calculates a cryptographic signature to prove possession of the private key So once again, the flow starts with the server generating a challenge, a large random number, which is used to prevent replay attacks Then the server transmits the credential ID and the challenge to the web application, which in turn calls the web authentication API Again, to create the cryptographic signature, you need to call navigator.credentials.get with the publicKey option You specify the challenge that you received from the server, the credential for which you want to get a cryptographic signature And here you see that you also ask the authenticator to locally verify the user In addition to these parameters that we just specified, once again, the browser extracts the authoritative domain name of the co-linked web application and sends all this information to the authenticator The authenticator looks up the information stored for this credential ID Next, and this is very important, the authenticator checks that the domain name of the calling website matches the one that was provided at the time the credential was created This is what makes these authenticators resistant to phishing If Jane is on the phishing page with a slightly different URL, the authenticator will notice the discrepancy So next, if it is indeed the real website, the authenticator performs local verification using the fingerprint reader If the fingerprint checks out, the authenticator uses the private key to generate a cryptographic signature over the domain name and the challenge The API call is then resolved with the signature, which is sent to the server There, once again it is verified that it corresponds to the challenge and the public key And if it does, then the server considers Jane’s authentication successful As the last step, again, don’t forget to invalidate the challenge This concludes the authentication flow But if you have dealt with a large user base, you know that you cannot just replace your identity management overnight What’s also great about WebAuthn is that it enables you to adopt it one step at a time You can use more and more of the API to get more and more of the security and usability benefits First, you can use it as a drop-in replacement for the U2F API for second factor authentication Then with minimal changes, you can implement passwordless reauthentication before sensitive operations such as making a purchase For instance, this can be done using the fingerprint reader built in to a phone or a mobile device And finally, once your users warm up to the idea of signing in using a fingerprint or a hardware token, you might even consider making it their primary login mechanism To summarize, we talked about the Web Authentication API, which provides strong authentication on the web using public-key cryptography It brings new features and form factors that enable a passwordless login experience, making it very easy for your users to sign in to your site securely And it all comes in the form of a simple-to-use, standardized, open web platform API which is available across all platforms and browsers With that, let me hand it back to Eiji to wrap it up [APPLAUSE] EIJI KITAMURA: OK, thank you, Balázs So we’ve been walking through three new exciting features for the web– One Tap Sign-Up and Auto Sign-In for ultimately low friction signing up and signing in, reCAPTCHA v3 for zero friction bot prevention, and Web Authentication for stronger authentication with open standard API I have just tweeted with hashtag #I/O18, but we have published an article about it By now, you should have understood what makes good sign-up and good sign-in– great security, great user experience, and great developer experience If you have any questions, please

visit us, the web sandbox, which is right next door And finally, we’d love your feedback on our session today at google.com/ioschedule With that, we hope you enjoyed our talk Thank you very much [MUSIC PLAYING]