 Do you wonder how a world would work without passwords? What is the technology that allows us to authenticate ourselves without passwords? How does it work? Hi, I am Sofia Prosper and in this video I will explain how the technology behind passkeys works to get rid of passwords with simple and easy to understand illustrations. Let's go! Frankly, aren't you sick of remembering or rather forgetting passwords? Even if you have a password manager, you have to remember at least one. Apart from feeling something tedious to remember, sometimes it's the only thing that lies between a malicious user and not your personal information, bank account, email, health information. You get the point. So passwords are not as safe and convenient as we used to think. They have many, many issues, like phishing. Phishing websites can easily harvest passwords from even the most tech savvy. Remote replay. Accounts can be accessed remotely using harvested passwords. Data breaches. Applications become a target for data breaches when they store passwords. Share and reuse. Reusing and sharing passwords makes them even more vulnerable. Knowledge base. There are too many services and passwords to remember. Passwords also make people a target for social engineering, which accounts for more than a half of the data breaches. Password management. They need reset and recovery flows, MFA implementations, password managers, and so on. Guess what is the technology that solves all these problems? If you are thinking of passkeys, you are right. A passkey is a unique cryptographic keeper allowing you to access services without passwords. It is based on a symmetry public key cryptography. Simple, right? Well, okay, it is not that simple if you don't know all those words that I just said. So let's break it down. Let's start with public key cryptography. A symmetric public key cryptography involves a pair of mathematically linked keys. A public key, which is shared openly, and a private key, kept secret by the owner. When a message is encrypted with the public key, only the corresponding private key can decrypt it, ensuring confidentiality. At the same time, a message signed with a private key can be verified with the public key, authenticating the sender's identity. These keys are generated using cryptographic algorithms, such as Erasey. And for passkeys, we make use of the signature verification aspect. Passkeys are a technology developed by the Fido Alliance. Fido stands for fast identity online. And it's a global authentication standard based on public key cryptography. It aims to solve all our password problems. Fido 2, it is a set of specs used for passkeys and web authentication. But what is web authentication? It is a W3C recommendation that lets a web page use a set of JavaScript APIs to talk to an authenticator to confirm the user identity. There are two types of authenticators. Platform authenticators that are built into the user's device. For example, the Touch ID or Face ID from Apple, small for authenticators, Windows Hello, and so on. And on the other hand, we have roaming authenticators that are removable devices usable from any device the user is signing in from. They are attached using USB, MPC, and or Bluetooth. For example, the security keys, like UV key, and also smartphones. In the architecture of Wafal thing, we can find three main entities. The authenticator, platform, or roaming, lets user authenticate by confirming their presence. They're relying party, a server, custom implementation, or an identity provided like out zero that requires authentication. It issues challenge and stores public keys. And the client consists of the end user and the browser's user agent. The client relays information between the unauthenticator and a relying party. Now that we understand some of the technologies behind pass keys, let's go through the types of pass keys that we have. We have two variants, synced or multi-device pass keys and hardware or device bound pass keys. In the synced pass keys, the private key is synced across devices and it gives you a better user experience. For example, on Apple devices the private key is synced to the iCloud Keychain which allows you to register on one device and logging to any synced Apple devices. The same goes for Google devices with Chrome. These pass keys can be restored on new devices. However, they are less secure than single device bound pass keys because they reside on the cloud, which can be theoretically breached. On the other hand, in the hardware or device bound pass keys the private key stays on the device itself and you need to authenticate using the same authenticator used for the registration. It is slightly less convenient but more secure than the synced pass keys. So how do pass keys work? Let's see how the registration flow works for pass keys. This is Matty, a user that wants to register on the coolest website ever. Matty, the user, begins the registration flow. The reliant party, in this case a server, provides a randomly generated challenge string. The navigator.credentials.create API is invoked. And Matty provides approval using the authenticator. So Matty is attesting or confirming they are trying to register the new credential. The authenticator creates a private public key pair unique for the reliant party's domain and the user. In this case, Matty and the coolest website ever. The private key is used to sign the challenge. An attestation object is created which contains the public key, signed challenge, credential ID and certificate. The private key is stored on the authenticator. Note that for synced pass keys the private key is also synced to a cloud service for backup and roaming. This is the only place where synced pass keys differ from hardware bound pass keys. The client sign implementation passes the attestation object and other metadata to the reliant party. The reliant party verifies the signed challenge using the public key and registers the user by storing the public key, credential ID and user details. Now let's see what happens the next time that Matty wants to log in. You will see that the login flow works pretty similar except for the third step. Matty comes back to the coolest website ever and begins the login flow. The reliant party provides a randomly generated challenge stream. The navigator.credentials.get API is invoked. And Matty provides approval using their authenticator, again attesting that they won't authenticate. The authenticator retrieves the private keys for the reliant party's domain name. For synced pass keys, if the device is new, the private key is synced from a cloud service if available. This is the only place where synced pass keys differ from hardware bound pass keys. The user selects the private key for the user name. The private key is used to sign the challenge. An assertion object is created, which contains the signed challenge and credential ID. The client sign implementation passes the attestation object and other metadata to the reliant party. The reliant party verifies the signed challenge using the public key store for the user and authenticates Matty. Do you remember all the password problems that I introduced at the beginning of this video? Let's see how pass keys solve them. You have seen that pass keys don't rely on something you know. They rely on something you have and sometimes on something you are. So it's more secure from hacking and social engineering. Pass keys are phishing resistant since they rely on public key cryptography and are bound to the website's domain name, making it impossible to work on a spoof website. They are remote attack resistant because they rely on physical keys like platform authenticators with biometrics or roaming authenticators like UV key. The website only stores the user's public key, which is useless to an attacker on a data bridge on the server side. This makes the server less attractive to hackers. Pass keys cannot be reused since they are unique per service and user combination and they cannot be shared, except from Apple which lets you airdrop the pass key. They are discovered by the browser and the browser can auto-fill them for a service, making it unnecessary even to remember user names. They are easier to maintain. Sync pass keys are backed up by the platform and are recovered by default, making it unnecessary for the applications to implement recovery flows, MFA and so on. But I need to be 100% transparent with you. There are still some challenges when it comes to pass keys. It depends on the OS and browsing to implement the specs and we all know how that turns out right. This means the support may not be uniform and can become fragmented and we might never have the same experience everywhere. We need to rely on cloud vendors like Apple, Google and Microsoft to save the private keys in the cloud. Enterprise users might want more control and flexibility which could be a problem. For example, if an enterprise doesn't allow iCloud or Google on their computer, pass keys would not work there. And almost lastly, related to reset and recovery, there are no default recovery flows for hardware bound pass keys and applications might still need to implement recovery and reset flows to accommodate all use cases. And to be clear, browsing and OS compatibility is still catching up. If you want to learn more about pass keys, check out this website. But if you want to try them out, very fast do it with your zero account since pass keys it is available in all out zero tenants. Thank you for watching and happy pass keys!