 Passwords on their own are no longer considered a good way to protect user accounts. The number of phishing attacks is surging. Users get trapped on fake websites, which bad actors use to steal their passwords. People are using the same password across different websites. A single data breach on one site can affect all the other sites on which the same password is used. Even if you build a secure password system, people are still at risk when the password is the only protection they can use. We need a remedy for this situation. Hi everyone, I'm Eji, and I'm a developer advocate at Google. Today, I would like to explore with you a path to a world without passwords. To keep websites safe, users are often asked to create a complex and unique password and remember it whenever they come back to a site or app. But that's not an easy task for most people. Users can use standalone password managers and browsers that have a password manager built-in to manage passwords for all of their accounts. Password managers generate strong passwords, remember them, autofill on the right websites and synchronize passwords across devices. But there can be problems with the password manager solution. Not every person uses one. People still continue to use the same password, saved in a password manager. Further, password managers don't always work across platforms, and that can mean stored passwords are unavailable in some places. For example, passwords stored on Chrome are not available on other browsers. Passwords cannot assume that their users always have access to a password manager. We need to do our best to protect users. Ideally, we don't want to rely on passwords at all. But how? The good news is there is a solution. Web authentication, or WebAuthn, is a web standard that allows users to authenticate with a FIDO compliant device, called an authenticator. FIDO is a standard that defines an authentication mechanism. This standard has been widely adopted and made available on all major browsers. For example, a security key is an authenticator that literally acts as a key for an authentication. It's often used as a second factor for password-based authentication. Let me show you how WebAuthn works. First, the user must register an authenticator with the website. This is a one-time operation that happens once the user is signed in or during account creation. There are three participants in WebAuthn. The website front-end, the web server, and the authenticator. To register the user's authenticator, the website first obtains a challenge from the server which prevents replay attacks. When the website calls navigator credentials create, the WebAuthn dialog is displayed in the browser and the authenticator prompts the user to perform the ceremony. This important step makes sure this authentication involves a physical gesture by a human. The authenticator generates a unique public key pair for the user to prove the user's possession of the device. This generated key pair is only useful for the registered origin. This means even if a user is trapped on the phishing website, the credential won't be available. This is a Fido's unique characteristic which protects users from phishing attacks. The authenticator then signs the challenge and the credential is returned to the server. The server verifies the credential to see if the challenge matches. Once verified, the server stores the public key and the credential ID to the user's account. The next time the website needs to authenticate the user, the website obtains a challenge and a list of credential IDs that can potentially authenticate the user as the user may have generated several credentials for that website. When the website calls navigator credentials get, the user is prompted to complete the ceremony, the physical interaction with the authenticator. Once completed, the authenticator will sign the challenge and return the signature. Finally, the server verifies the signature with the public key. The user has been successfully authenticated. Security keys are an excellent choice for high-risk accounts or in enterprise settings. Having an additional device is warranted and easier to mandate in those use cases. However, this does not scale well to general consumer users. In fact, many users are already on other authenticators. They are Fido compliant and built into smartphones and computers. We call them platform authenticators. Platform authenticators usually integrate with a biometric sensor such as a fingerprint sensor or a camera with facial recognition. The ceremony performed on platform authenticators involves unlocking the device, which can involve a biometric sensor. Platform authenticators provided two factors in a single step. The user needs to physically possess the phone or the computer and they need to take an action to unlock it. To use a platform authenticator with WebAuthn, specify the authenticator attachment as platform and user verification as required on registration. The rest of the code and action is identical to the previous example. Since platform authenticators can verify user identity quickly, it's suitable for a sensitive operation such as making a payment or changing a password. Platform authenticators sound like a great solution to enable passwordless logging, but there are a couple of challenges. In the current Fido implementation, to authenticate a user, you need a list of credential IDs which requires that you know who the user is first. This leads to a suboptimal experience where we need to ask the user to provide their username before authenticating. Also, because platform authenticators are built into the device, they can only be used on the same device. Users may have to register multiple platform authenticators with their account to use multiple devices. Every time the user switches to a new device, they have to register its platform authenticator again. This means the website needs to keep an account recovery process available, a process which can lead to phishing attacks. This is a major blocker for eliminating passwords. To solve the username challenge, you can use discoverable credentials. With discoverable credentials, users choose an account provided by the device's operating system and authenticate locally to sign name, skipping username entry. This is made possible because an authenticator can remember the user account as a discoverable credential. This means in the future, you can create a super quick signing form where there is only a single button that invokes WebAuthn. This functionality has been supported in Chrome on desktop and other browsers for some time and is finally coming to Android later this year. To use discoverable credentials, pass an empty allow credentials object on authentication. Earlier, I mentioned you need to pass a list of credential IDs on authentication. As a server cannot predict which authenticator the user will use, you have to send all possible credential IDs. With discoverable credentials, the user can proactively choose the credential that is most suitable to sign name with. This allows the authenticator to create a signature with the private key. To resolve the second challenge, phyto credentials remaining on the same device, we have an exciting new feature called pass keys. You can consider pass keys a replacement for passwords, but they are phyto credentials under the hood. On Chrome, pass keys are synchronized across a user's Android devices. For example, if the user creates a pass key on a website on one Android device, the same pass key is available on another Android device as long as the user is signed in with the same Google account. There's no additional steps required for web developers to activate this feature on WebAuthn. With pass keys, users will no longer need to enter their passwords on new devices. This is a practical next step towards getting rid of passwords completely. Also, because pass keys are based on phyto standard, other platform providers such as Apple are working to enable similar functionality on their platform. But what if a user tries to sign in cross-platform? What if a user tries to sign in on a Windows machine, even though they only have a pass key stored on their Android phone? The answer is they can still use a pass key from their phone. When the user signs in to a website on a different platform for the first time, the WebAuthn dialog offers an option to sign in with a phone. By scanning a QR code, the user can locally choose an account and authenticate by unlocking their phone. Then the user is signed in on the other phone. The QR code authorization is required only once. The next time, the user can pick the name of the phone from the discoverable credentials list, skipping the scanning. And pass keys on Android will be available later this year. To see typical user journeys with pass keys, check out the IO session Android Authentication or App Developers by Jay and Diego. We are working on a code lab so you can learn how to build a sign-in using a pass key. Finally, you can learn more about FIDO and WebAuthn from Google slash FIDO. OK, it's great that WebAuthn is bringing the web platform closer to the passwordless word, but you can't remove passwords just yet. Because the development is incremental, there are compatibility issues and there might be users who don't have capable devices. Then, how do we secure a password-only website? What other options do we have? For your existing users with a password, adding a second step is more secure than just relying on a password. Many service owners, including Google, have already mandated a second step. The idea is to ask the user to enter a one-time password OTP in short that can be generated directly via an app or maybe delivered via SMS on an email. Sometimes this step uses a FIDO Authenticator such as a security key. This diagram shows how effectively different second step options protect a user from common attacks. The strongest option is a security key, so it's recommended because many users can now use their phone. But if the user already owns a phone with a platform authenticator, relying on pass keys instead of a password and the second step serves a much better user experience. It's more secure and it's more recommended. If you choose to allow an SMS-based OTP as a second step, be mindful that phone numbers are known to be recycled and hijacked. This method can make users exposed to phishing attacks. You can use Web OTP API on Chrome and auto-complete one-time code on Safari to optimize the user experience. The service provider sends specially formatted SMS messages which tell the APIs to provide the OTP for the user. This means the user doesn't have to leave your website to enter the OTP. Also, because the message includes the target origin, this method won't work when the user is on a phishing website. Both Web OTP API and auto-complete one-time code work on desktop and on mobile. Previously, I gave a talk about how to optimize SMS OTP forms. You can watch the video to learn more about SMS OTP forms best practices. Another secure authentication option without adding a new password is identity federation, which consists of standard protocols such as OpenID Connect, OAuth, or SAML. With identity federation, a reliant party or RP can delegate its authentication mechanism for user sign-in to an identity provider or IDP. The IDP provides an authentication mechanism to a third party. For example, a lot of you must have signed into Google iOS website using your Google account. That is exactly how identity federation works. Identity federation is great for users who don't want to create and remember a new password. But some people may be concerned that IDPs can learn which RPs that user visits, or they wonder if its third party cookie can be used for tracking. That's why we are working on a new browser API dedicated for identity federation called Federated Credential Management API, FedCM, in short. FedCM is an API that makes identity federation more privacy-preserving. Let's look at an example of a user journey that FedCM supports. Let's say your website is an RP. As soon as the user lands on the website, and if the user is already signed into the IDP, a dialogue pops up. By tapping on the Continue As button, the user creates a federated account and is signed in on the website with their identity provided from the IDP. This integration is designed with user privacy in mind. Because the browser mediates communication between the RP and the IDP, the user's sign-in state and their IDP account information is not revealed to the RP until the user agrees to sign in. Which RP the user is trying to sign in from is not revealed to the IDP until the user agrees to sign in. And most importantly, FedCM is designed to work without a third party cookie which could allow user tracking. We believe that this is a great first step to improve user privacy with the identity federation. FedCM is still at an early stage and we want identity providers to try it and give us feedback. You can try it by enabling a FedCM flag. FedCM currently works on Chrome on Android, but is coming to the desktop soon. And the WebKit team has expressed an interest in working on the FedCM proposal. You can now participate in an origin trial which allows you to enroll your website to enable experimental features in production environments. To learn more, visit Google slash FedCM. I'm looking forward to hearing your feedback, especially if you have any concrete third party cookie related concerns around identity federation. In this talk, we've covered a lot. Let me summarize. The ultimate passwordless word is becoming protocol with pass keys, which will be available soon. Meanwhile, since the transition is incremental, it's important to keep users safe by adding a second step for password only users. Using identity federation is also a great option to protect users. The Federated Credential Management API is proposed to create a privacy preserving method for identity federation. If you are an identity provider, consider participating in the origin trial and give us your feedback. I'm looking forward to seeing a word with a password soon. Thank you for watching.