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

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. We. Only have a few hours left, for. Rest. Of Google i/o but I'm. Pretty sure we'll be excited to learn. New, things from this session, okay. So. I, need. To have this clicker. So. Let me start with this question and. 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 name sign-in. Mechanism, means, giving. Attackers, a chance tube, abusing, 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, it. Creates more Elvis circles and brings. More, friction for your users to enter your your, website. Thinking. About users, 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 user, flow, the. Rippers tend to be more excited, about new, ideas and. Innovative. Features and pay. Less attention to, make, 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. Without. In mind today. We'll, cover three, topics, want, up sign up and Auto sign in. Recapture. A victory, 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 users safety. Heavily, relies on how. They creates their own passwords. Their. Passwords, could, be weak forgotten. Reused. Or stolen. Balázs. Is going, to explain more about this. These, challenges later in this 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 identity, provider. Identity. Federation, is usually. Built upon standards, called. Such. As Open, ID connect or OERs. 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 dydg provider and. As. Many of you know Google. Is one of such IDC providers. You. Can already take advantage, of Google, 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 signup easier, and at. Chrome dev summit last. Year we've officially announced, it as. One. Top 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 top. We have 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. Red. Bean a real estate company in the US. So. An eighty percent increase, in signups after, implementing one tab signup. Also. Over. 40 percent of these, new users return 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, fifty, percent more new signups with. Twice as many signing users after, implementing this library. Six. Lakh Club. Lettres. And Park on popular. Music sites, in Brazil for, chorus, lyrics and songs, got, 43.

Times More users signing up after, integrating one tab sign up this. Is not a typo, I said, forty three times which means four, thousand. Three hundred percent, more, users that's, incredible, number and user. Engagement such. As favoriting, artists, creating. Playlists or commenting, liking chords, has also increased almost, fifty, percent per. User, this. Is impressive. So. Here's, how it works. The. User operates user. Opens the signup page, selects. One of the Google accounts and they're. Signed up it's. Just that it. Takes less than ten seconds, the. Animation the slide might be a too quick to catch up what's going on but it's, actually that easy. What. The 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, partial, less and requires. Only one top for, users to sign up. Know. E-mail verification is, required. Think. About it you. Have to open, up email, client, find, the right email and click, a link in that email. It's. A kind, of a hassle right you can completely. Eliminate that. Step. From, the user it's, a big deal and, third. It. Works across, modem, all modern browsers. Using. This API is quite simple, start. With loading, this JavaScript library. Once. It's loaded show. A sign up ladder by, calling this method. Google, yellow dot 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 the you will receive a result that contains, an ID, token, use. The ID token to verify the. Users identity on your server, if. You already have a Google sign-in back-end, you can reuse it. What's. The ID token is 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 them, live. You can let the user sign, back in automatically. To. Perform, auto sign name just, call Google, real Google, your retrieve, to, obtain the user ID token, then. You can use the ID token to let the user sign back in and resume. A session. By. The way you, might have heard about an API called the credential, management API. It's. An open Web API, to handle, credentials, using javascript. The. Multiply, bree, actually. Uses this credential.

Management, API behind, the scenes if the, browser supports it and there. Is a sort password, for the website. If. You want to retrieve, an existing past, at Google or Oh 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. He when a user clicks the sign up button the. User probably wants, to keep, signed out in. That case called. Google, reload disable. Auto sign, in that. Way Google, euros retrieve, will stop returning ID token until. The user explicitly. Signs. Back in. So. That's the one tap sign up let. Me recap. One. That sign up is secure, because, it's, Google's, identity, Federation, it. Provides. A great user experience, for. User to. Sign up with just one tap and auto, sign. It's, easy to implement with sibling. Simple, api's. To. Learn more about want to sign up, please. Visit developers.google.com, slash. 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 password, a username, and password. Earlier. In this session I talked, about challenges with passwords. What. Can you do if an attacker already. Knows your, users, password, and tries to hijack. Account. And. In. Many cases, account. Hijacking, is done, by BOTS. This. Means if you could filter out both, the, number of account, hijacks, should, decrease, and. That's. What we captured us. Six. Years ago it. Asks users to read a distorted. But. We knew we could do better. We. Then developed, recaptured, v2. Where, users. Can simply tap a check box to verify. V2. Is smart. Enough to determine, if an interaction. Is abuse, 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, two million websites, every week from spam and abuse. But. What. Evolve also. The. Attacks against, reCAPTCHA over the last few, years last.

Several Years have evolved, from brute force or random. Guest spots to. A smarter. And even, AI best spots, they. Began to bring machine. Learning solutions, and abusive, humans, to, try to break these challenges, and attack, websites. But. We want to stop but whether, or not they, can find the street signs in a, set of images. Today. We, are announcing public. Beta of recap gia v3. This. New version comes, with three, new things at a high level. First. It, requires no. Interactive. Challenges. To. Its, cores traffic. With the adaptive, risk analysis, engine and third. It breaks down your traffic by actions, let. Me walk you through each one. In. D3, reCAPTCHA. Detects, weather and interaction. With your website is abusive. Without, even, a single tap, this. Means you can keep your website with, safe without, interact, interrupting. Any users, and. Instead. Of 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 will you can define, your own threshold, to. Determine whether you you. Should do. Further verification on the request. Let's. Say you get a login request with a barely 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. Certain, 30 requests, from bots as a protection, from scraping. To. Use reCAPTCHA. First. Load the devil script library. When. The user submits the form regressive. ReCAPTCHA token and. Finally. Submit, the form along with the obtain token. One. Nice thing about v3, is that it enables you to put it into, almost. All, parts. Of your website, not. Only the signup page but. Also many, other places, for. Example from. Home page to. Reading path 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 for. Action in the, reCAPTCHA, admin console. So. That's, reCAPTCHA. V3 let, me recap, recap. Jia 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, be three pleased. With it did our CEO slash slash, recapture. V3. IO. Okay, I've been talking about to lurch features, from. Google, but. I'd, like to make a transition, to talk. About open, Web API. The. Credential, management API I briefly, I briefly, talked about it earlier, in this session as. I said what, the signup, contains. The credential management API but. It, focuses on identity, Federation, with Google if you choose, to use other identity, options, such as user. Name and password you should use credential, management API, we. Have already covered this topic at Google. I/o last year so. Let me quickly lick 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, them or sending. With browsers native, account chooser. It. Can, handle two different types of credentials. First. For credential, and, Federative. Credential, and now. We. Have a new type of credential being. Added, to this API which. Is called public, key credential. With. That let, me invite Bosch, to talk about web authentication. Thank. You AJ. Hi. Everyone i'm, balázs, i'm a software engineer on the chrome web, identity, team and, AG. Already, mentioned that passwords. Create a number of issues I would. Like let it I would like to talk a little bit more about two of them in particular the. First one is password. To reuse when. Your users are using the same password on multiple different websites, and the, second one is fishing, 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 user users, let's, call her Jane Doe has, accounts, on 50, different web sites 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, will be reusing that password on ten different websites 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 ten web sites 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. Breach is 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 are using two-factor, authentication. To. Login 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. OTP. Zarf aged 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 web site and, initiates. A login flow using, the freshly stolen password. The. Real web site 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 into the real web site 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 then simply forward 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 with Riya 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, twelve point four million users, fell, victim to phishing during, the same one-year, period, this. Is my 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. The. Main event, made the 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 the, 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. Can 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 YouTube 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 my I'm 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, 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. Its, backwards, compatible, with existing YouTube security, keys the. Very same key that you registered, through the YouTube API can. Now be used through, the web authentication, API, that. Means that you can migrate your site from, u2f, to web often without, any user visible changes, but. Web Alton is much, more than just a new API. Web. Ulsan also, enables, authenticators. That, come in a 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. Webathon, 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. Weber then the. Built-in fingerprint, reader in your notebook or phone, can. Also become a user verifying, Authenticator. Regardless. The phone 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. We switch 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 picture to phone with a fingerprint, sensor, so. Suppose I have this camera, cleaning, quit that's really nice that's a really good deal for just 10 cents so. I add it to my cart. Then. I go to, checkout. And. Then. I choose to complete my checkout with PayPal, I. Get. Redirected to PayPal and. Because. PayPal. Supports the web authentication API, I can, easily verify my, identity using. Just my fingerprint. Sorry. Select. The credit-card. Shipping. Address. Then. 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 user, experience. Back. To the slides please. So. How, does that all work, first. Let's, take a look at how, authenticators. Work in the first place all. Web, FN authenticators. Use, public, key cryptography, there. Is a one-time, setup 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, a 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, is sent to the web server which. Verifies it against the public key and the challenge, with. User verifying, authenticators. Releasing. This 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 type setup flow in more detail you did not seen 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. Kick off 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. A 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 codes as AG. Mentioned webathon. Extends, the credential, management, API so, it's available under. Navigator, dot credentials, to. Create a new public, key credential, you call create with, the public key 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, we 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, resolved. With the public key credential, which contains, the unique identifier, the, public key and the signature calculated. 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 is, the last step, if. The signature checks out the, server has, stored 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, Jain can, use the Authenticator, to, log in without a password, the next time, the. Starting, state here is that, the Authenticator, already. Has a private, key and, server has, a corresponding, public key in association. With Jane's account remember. That, authentication, is performed, using a challenge response based protocol, where, 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's transmits, the credential, ID and the challenge to the web application, which, in turn calls the web authentication, API. Again. To. Create a cryptographic signature, you, need to call navigator, credentials. That get with the public key 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 we 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 calling web application, and sends, all this information, to the Authenticator. The. Authenticator, looks, up 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 a phishing page with, a slightly, different URL, the, Authenticator, will, notice the discrepancy. So. Next if it, is R indeed through a web site 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 done resolved, with this 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 consider, Jane's. Authentication. Are, successful, and. Last step again don't forget to invalidate the challenge this. Concludes, the registration, sorry 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 web FN is that, it enables to 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 password. That's real and occasion 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 password, S 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 AG to wrap it up. Okay. Thank. You bash so, we've been walking through three. New exciting features to the web one. Top sign up and the auto sign game for, ultimately, low-friction. Signing, up and sending, in. Recapture. V3 for zero friction bots, prevention, and, web. Authentication for, stronger authentication with, open standard API I have. Just tweeted, with hashtag, IO 18, but we have published, an article, about, it. By. Now you, should have understood, what makes good, sign up and good sign name. 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, slash IO schedule. With. That we. Hope you enjoyed our talk thank. You very much.

2018-05-12 12:34

Other news