 This is Ibshah and Ankit from India. So like next door's neighbors. And we are really excited to be here today for the second time in the last three years. And it's all been possible because of the amazing organizing team and everyone who works so, so hard to make this event a success year and again. So thank you. We both work with Jamalto in the domain of Digital Security, which is now a part of Thales. Today we are going to take you through this journey of what's going on in the world of authentication, what's new, how everything works under the hood, what new technologies have come up in the last few years, and basically why should you care about it all? So everything revolving around authentication. So basically to start with, when I flew into UK, the officer at the immigration asked for my name. So basically that's me identifying myself and then the gentleman asked me to patent my fingerprints to verify it is indeed me, Ankit, who I claim to be. So that is authentication. And now even though I'm allowed to roam in this beautiful city, yet I cannot meet the queen. So because I'm not allowed to do that. So that's authorization. So identification, authentication, and authorization, who you say you are, who you can prove you are and what you can do. So now before we talk about what's new in the authentication domain, let's talk about what's old, passwords. The most basic and vulnerable form of authentication is when you provide a username and a password. Think about it, that digital world has evolved over the years, but we are still using the same technology of username and passwords that was devised over 50 years ago at MIT to control the amount of students and professors could spend on the university's time share computer. Now that so much sensitive personal and financial information is stored online and sent over the internet, there is a greater need to invade the way as we authenticate, now more than ever. As we get closer to the 16th anniversary of digital passwords, the calls to ditch the technology are getting louder and more widespread. As we have seen, the vulnerability is related to this in terms of hacking passwords and breaches over massive scales, time and again. And as you can see in the image, identity theft is the most common one, breach and it has been the most common source of attacks since years in a row. And it is rightly said, just as nuclear war, the strategic warfare of the industrial era, cyber warfare has become the strategic war of the information era. And now we have seen some massive data breaches over the years, like in the late 2014s, Yahoo's account was hacked over half a billion accounts leaked in a large scale data breach. Yahoo has confirmed that over 500 million users' accounts were exposed in this massive data breach. Same happened with the Dropbox, where 68 million user accounts were compromised in the 2016, where attackers exploited an improperly secured employee password to obtain the email addresses and hashed and sorted passwords from breach to account that were created in the 2012 and earlier. There is one more case with the LinkedIn. The accounts of 170 million people were compromised in 2012, but the data stayed in a private hands until it is unexpectedly appeared on the dark web in the 2016. So it is actually very common to see data being breached and accounts being hacked. In fact, if you're not aware, there is a very cool website that lets you check whether any of your account has been compromised in any of the data breaches or not. So you just browse this website and enter your email ID and it shows you a record of breaches related to that account, if any. So do check this out if you are interested. So moving on to then, what is it with passwords that makes them so unreliable and undesirable when it comes to security? So basically, there are some problems with the password. The first one is passwords are simple and they are easy to crack. So let's take an example of Amazon.com. So if you want to register yourself on Amazon.com, you can just provide a password. So basically the password that you can provide there is only six, it only needs a six characters long password without any special characters or anything. So you can put it like one, two, three, four, five, six, or A, A, A, A, A, A, whatever you want to do. And in fact, according to a security company, Splashdata, the two most commonly used passwords are one, two, three, four, five, six, and the name password itself. The second one is the complex ones, which are hard to remember. So while recommendations on using cryptic and hard to guess, and hence remember passwords, which leads to what? Tightening the rules for setting passwords. So suppose there's an organization that wants you to set a password that is hard to guess. Suppose think of a word, a password. You need to make it at least eight characters long, but not more than 12. Don't repeat any of the characters more than twice. Make sure it has at least one number. And in fact, it has to start with a number. You can't use a username or any password. You have tried in the past. And finally, you have to use one of these special characters somewhere in your password. The third one is, so the second one leads to the third one, if you use a complex password, which is hard to remember, then what you end up with is you end up with resetting your passwords the next time you log in because they are hard to remember. So what it does is they are hard to remember what you would do. You will write it down somewhere so that you can remember it. Or you just reset it the next time you enter in your account, which means extra time spent by the users and IT for resetting the passwords. And on an average, the IT persons spend over 12 minutes per month for a user if any of the passwords are being resetted. And the fourth one is reusing passwords. So basically this creates a domino effect that allows hackers to multiple accounts just by cracking a single password. So as you can see in the image, these are the top 20 most common passwords of 2019 and one, two, three, four, five being the winner again. So now to recap the problem with passwords, let us quickly look through how it is actually going, goes while dealing with the passwords. So suppose you set up an easy to remember password, but then it's too simple. So then what you would do, you will write a hard to remember or a password that contains special characters and is not easy to hack. So the website ends up having complex requirements for setting the password and which eventually leads you to write them down somewhere like this and now because the password is so complex, you either keep getting it wrong or end for getting it all together and if you then go through the pain of resetting your password. Even after successful password change, you keep entering your old password for a really long time which eventually makes you want to get rid of the passwords. So we saw a bunch of vulnerabilities related to the traditional way of authenticating that is using a username and password. Now, when we talk about authentication, there's basically two aspects which we can use to determine how strong the mechanism is. So it's not just about being very secure, it's also about the convenience for the end user and one of the biggest hassle with the traditional way of authenticating is to maintain and remember complex passwords for multiple accounts. On an average, a person has about 20 to 30 accounts, be it for social media account, finance, e-commerce, et cetera. So what we try to achieve is find a perfect balance between how secure the mechanism is for authenticating a user versus how convenient it is for the end user to actually authenticate to the application or the service. So we can have the most secure of all passwords which is complex, hard to remember, unique, for one, two, maybe five, but as the number grows, managing all these passwords become a hassle. So naturally it made very less sense to have multiple accounts for one user even if they are for different purposes. That's where the concept of a federated identity came into the picture. This is there to make access to multiple services more convenient. Federated identity is basically reusing your authenticated identity to log into different sites. It is one of the most commonly used mechanism in today's world to authenticate to make the process of login to end to multiple applications more convenient. You may not know it, but chances are you are already using this in your daily life. When you visit a new application over the internet, it either asks you to register as a new user or maybe sign in or log in via Facebook, Google, Twitter, etc. So you're basically in this scenario reusing your identities on these platforms to gain access to a new application instead of signing up as a new user. So here in the technical lingo, Google, Facebook or Twitter becomes your identity provider that is providing you an identity and the application you are trying to log into becomes the relying party. The application has outsourced the user authentication step to a trusted IDP or identity provider. The relying party in this case is also known as the service provider because as the name suggests, it is the entity that is providing the services to the end user. So what does it really mean when you say that my authentication is federated out to ABC? In the simplest of terms, instead of the service provider authenticating the user itself, it has offloaded the authentication to another system. The service provider is no longer storing the user credentials or validating them. Instead, the IDP validates the user and notifies the service provider that the user is indeed who they say they are. The service provider here is simply trusting the authentication capabilities of the IDP. So the identity provider is offering user authentication as a service. Now, the beauty of using an IDP is twofold. Firstly, it saves you, the end user, the pain of creating and maintaining multiple passwords for new accounts. And secondly, it spares the third-party application the trouble of storing and protecting that information. In fact, since the authentication process is now relayed to Google or any other trusted identity provider, the third-party website never sees your password or any other authentication credentials. And this single consistent identity being used across platforms, applications, and networks is called a federated identity, which gives birth to the concept of bring your own identity. Now, such a thing is also very common at the enterprise level where a company makes use of several web-based applications within their network and wishes to issue the employee a single set of credentials between the apps. So in this case, here Microsoft's Active Directory, AD, can act as an identity provider. In fact, majority of you here must be using this on a daily basis in your corporate life. This basically is referred to as single sign-on, or SSO. The application vendors when they sell their product to various corporate to access, which you might need some credentials. Without the concept of SSO, the employee has to log in to their corporate network, fire up a browser, go to the application URL, and then log in to the application again. So to save this trouble and to provide a more user-friendly flow of things, the IDP validates your credential once and simply grants you access to all the application at your enterprise level based on that. And it is not just convenient for the end user, but also for the IT team. Imagine having to maintain separate accounts for each services, their password resets, and user provisioning or deprovisioning in case some employer leaves the organization. It all seems too much of trouble to deal with, which could be solved using SSO. And of course, there's always this argument of having all the eggs in one basket, but think of it this way. If you're limiting the authentication process to one server, you can basically apply all your expertise into protecting that one server as opposed to having it on different servers maintained by different teams. If you look at the example of Google, even they do a similar thing. When you go to google.com and you click on sign in, you are basically redirected to accounts.google.com. Similarly, if you go to youtube.com and you click on sign in, you are again redirected to accounts.google.com. So in this case, that is one centralized server that is responsible for authenticating you, and once you authenticate it, it redirects you back to the application that you were trying to access. So very quickly, let us look at how the federated authentication works. In this example, we assume the user is using a browser to access the service provider, and the IDP is using an authentication flow using employee redirects. So first, the service provider may have a mechanism of checking if a user is currently authenticated by any session state maintenance. In some cases, the service provider will always redirect to the IDP login page and check the current user state. If the user is not authenticated, they are redirected to the IDP page where they put in the credentials. When you submit your credentials, the IDP validates the credentials and returns back the user to the service provider, if valid. In addition, the IDP creates some signed data to send back along the HTTP request. This data tells the service provider, the user has successfully logged in, among many other things. The service provider now validates the data, and if it is found to be valid, the application can treat the user as authenticated. Now here, one of the most important things in its working is the concept of trust, which is also called the Relying Party Trust, which basically means that the service provider trusts the IDP, and the IDP trusts the service provider to be who it claims to be. This trust relationship is usually managed using different steps of keys, encryptions, or PKI. So Ankit here would explain different protocols related to it. So this is the basic workflow of how things work in a broad expect, keeping out much of the specific details. Specifically, what this data is, how the validation of the data is done, and other important specific security details, which are tied to the implementation. What you should see is that the service provider never dealt with the user's credentials. The validation is done by the IDP and used a secure data format to communicate a successful authentication. This could be a XML, a JOT, et cetera. So there are a bunch of different protocols that are used to implement this concept, and even though the underlying concepts, components, and concepts broadly remains the same, they differ in data formats and use cases that they serve. Without going into minor details, let us quickly go through some of them. The first one we will be talking about is OWAT, version 2.0. So OWAT is about authorization. That is, I can grant permissions to some website to access my data from another website without actually sharing the user credentials with the original website. So suppose let's take an example of LinkedIn. So when you log into LinkedIn, and LinkedIn wants to import your contacts from your Gmail account. So what it do, it will ask the user that I want to access your Gmail accounts and I want to import it to my account. So it will redirect the user to the Gmail's login page where user enters his or her details about the user and password, and the Gmail is doing the authentication over there. Once the authentication is successful over there, the Gmail ask the user whether the user wants to authorize LinkedIn to access their Gmail contacts or not. And on successful authorization, Gmail redirects back to the LinkedIn saying, hey, hey, LinkedIn, you can now retrieve contacts from Gmail. The user has authorized you to do so. And LinkedIn then imports the contacts from Gmail and tells the user that I have successfully imported the contacts from Gmail. So how OWAT works, it works by delegating user authentication to a service that hosts the user accounts and authorizing third-party applications to access the user account details. OWAT 2 basically provides authorization flow for web and desktop applications and mobile devices. So before moving on, I would like to discuss some of the roles that are in OWAT. The first one is the resource owner. So resource owner is basically the one that is... So basically the one the resource is there for. So the user here is the resource owner. The second one is the authorization server. And from the example, you can link it to like that. The Gmail here is your authorization server, which is authorizing the user that... And authentication and authorizing the user. And the third one is the client, which is the application that wants to access the user details. So in this example, LinkedIn is your client. So before using OWAT with your application, you must do one thing with your application. You need to register your application with the OWAT provider. This is done through a registration form in the developers or API portion of the services website, where you will provide the details about your application and some of the details are. So basically what you are seeing here is an OWAT application registration form for GitHub. So here you need to provide your application name, the name with which you want to register your application. The second one is the application website, which is the homepage URL of your website. And the third one is the redirect or callback URL. So basically this is the URL. The authorization server will be redirecting back after successfully access granted or deny status along with the authorization or the access codes in case of the access is granted. So now we'll look at the flow of the protocol to understand the components involved and how it is actually done. So as you can see in the diagram, the first step is when the user tries to access the client, application using login via some other website for the, let's say, Gmail, Facebook, or Twitter, then the client application first checks whether the user is already logged in or not on the IDP. And in case the user is not logged in in the IDP, then the client application redirects the user to the IDP's login page. The user then enter his or her credentials on the IDP's login page. The IDP verifies the user credentials and on successful verification, the IDP has the user. That this application, the client application, want to access these details of yours, do you want to grant the access or not? And if, suppose if the user says yes, I want to grant permissions to this application to access my details, then the IDP sends the authorization code back to the client application. Now, when the client application wants to access the user details, it needs to send the access code that it gets in the previous step along with the client ID, client secret, and its request to gain access to the user details. Once the IDP receives the access request from the client application, what it does first, it verifies the client and the authorization code that is being set in the sent in the request. And after successful verification of the IDP returns an access token, which is in the form of a jot to the client application. Once the client application gets the access token, it requests the IDP to get the user details. The IDP then verifies the access token if it's a valid access token or not. And if everything is correct, it returns the user details back to the client application. So now we know what OAuth is responsible for and how it is working under the hood, which is it is only responsible for the authorization and delegates the authentication to some other service. What if we don't want to delegate the authentication to some other service and wants to do it on our own? So there are protocols through which you can handle both, i.e. the authentication and the authorization to the resources. And let's have a look at them. The next one that we will be discussing is SAML. So basically, SAML stands for Security Accession Markup Language, which is an XML-based standard for exchanging authentication and authorization data between IDPs and the service providers to verify the user's identity and permissions. And then it grant access or deny the access to the services. SAML grants or deny access by the use of assertions in the XML request response messages that it sends over the HTTP or HTTP S. So basically, there are three types of assertions that we would like to talk about. The first one is the authentication assertion. This proves identification of the user and provides the time the user logged in and what method of authentication they used, i.e. whether they used Kerberos or two-factor, et cetera. The second one is the attribute assertion. They are specific pieces of data that provide information about the user. And the third one is authorization decision assertion. An authorization decision assertion says if the user is authorized to use the service or if the identity provider denied their request due to a password failure or lack of rights to the service. So in spite of being so famous and widely used by various applications, there is one major limitation to this protocol that it is designed only to be used within a web application. This means in order to use SAML with your mobile or desktop applications, you need to do some extra efforts or workarounds to achieve that since SAML is basically all about HTTP redirects, which is hard to handle in a mobile or desktop application. So now, what if we want to achieve SSO in our web mobile or desktop application altogether without putting extra efforts or any workarounds? So there is another protocol that is OIDC, which stands for OpenID Connect, that you can use with any of the application to obtain basic profile information about the end user in an interoperable and REST-like manner. So OIDC is basically made up of two protocols. The first one is OpenID. It is a protocol that is responsible for the authentication mechanism, and the second one is OAuth, which is responsible for the authorization, which we have discussed in the previously. So OIDC is an authentication layer basically on the top of OAuth 2.0, an authorization framework. Like SAML uses the XML for its request-response messages, OIDC uses Jot, which is a JSON web token. For that, OpenID Connect allows clients of all types, including web-based mobile and JavaScript clients, to request and receive information about the authenticated sessions and end users. So since OIDC is a combination of both the protocols, which is OpenID and OAuth, the part till where we get the authorization code is same as in OAuth. The difference here is that the IDP that we are using for the authentication can be our own IDP, basically handling authentications as well, or it can be any other IDPs like Google, Twitter, Facebook. There is one more difference, which is when we are making a request to get the authorization code from the OIDC provider, in OIDC protocol, we need to add the scopes in the request. So basically in the HTTP request that you are making to the IDP, you need to specify what scopes are that you want to use, which is basically added as a query parameter in the request URL. The standard OIDC scopes are, the first one is OpenID, indicates that the application intends to use OIDC to verify the user's identity. The second one is profile, which returns claims that represents basic profile information, like name, family name, given name, et cetera. And the third one is email, which returns the email claims, which contains the user's email address. The first scope that is the OpenID scope is mandatory one. The rest are the optional based on the requirements. Once the client application gets the authorization code, it calls the token endpoint of the OpenID Connect provider to get the ID token and or access token altogether. The access token it gets from the IDP is the same as we get in the OAuth protocol and is used to make subsequent API calls to the OIDC endpoints at the IDP. The ID token is a new thing that was not there in the OAuth and is introduced in the OIDC protocol. So ID token is basically a jot that contains the claims, as we have discussed earlier above, about the authenticated user. The client application can get the user details by decoding this ID token. If the application needs the user details again for some purpose, then it can also directly call the user info endpoint of OpenID Connect provider along with the authorization code received in the first step. So basically that's all for the protocols and how they are actually working at the back end. So Napsh, Ipsha, we'll continue. Ankshankar for explaining in detail how different protocols work. So till here, what we saw was basically the concept of convenience, like not having the user to have or maintain multiple accounts and basically reusing your identity over multiple application services and stuff like that, but with the introduction of this concept of identity, which is federated, there comes one argument against it that now since only one server is maintaining all your authentication, it has to be really secure. So all the talks about the convenience factor of authentication, but with ease and convenience, the need of having more secure authentication is now becoming of utmost importance for the IDP itself. Since now there are a larger number of things at stake here. So how do you make sure that the method that you're using to authenticate a user at the IDP is itself the most secure? The first one very obvious solution is of course to increase the layer in the process of authentication by introducing multi-factor authentication. Multi-factor authentication or MFA creates a multi-layered mechanism that an unauthorized user would have to defeat in order to gain access to a resource. Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. The intent of multi-factor authentication is to provide a higher degree of assurance of the identity of the individual attempting to access a resource. So at the core of MFA, it majorly has a combination of three types of authenticating factors, that is knowledge, possession, and inheritance. So first knowledge, something you know such as password or passphrases. This method involves a verification of information that a user provides, such as password or passphrases, pins, or the answers to secret question, which is basically challenge response. Possession, something you have, such as token, device, or smart card. This method involves verification of a specific item a user has in their possession, such as a physical token, an OTP token, an employee access card, or a phone SIM card. And finally, something you are, such as biometric. This method involves verification of characteristics inherent to the individual, such as wire retina scan, iris scan, fingerprint scans, finger vein scan, facial recognition, hand geometry, and even ear lobe geometry. Other type of information, such as geolocation and time may also be additionally used to authenticate. However, at least two of the three factors mentioned earlier must be used to identify a user. So as you can see, different types of multi-factor authentication may include all these things, SMS voice, OTP, push, physical tokens, biometrics. But one of the most important things here to note is that the authentication mechanism in multi-factor authentication should be independent of one another. Such that the access of one factor does not grant access to any other factor. And the compromise of one factor does not affect the integrity of the other factor. So basically all the factors that you are using to grant access to a user has to be independent of each other. For example, if the same set of credential is used as an authentication factor and also for gaining access to an email account where a secondary factor, say, OTP is sent, these factors are not independent. Similarly, a software certificate stored on your laptop, which is something you have, that is protected by the same set of credentials used to log into the laptop, which is something you know, may not provide independence. If this is not followed, it simply becomes a multi-step authentication as opposed to multi-factor authentication, which is what we must strive to achieve. And indeed adopting multi-factor authentication has shown rewarding results for organizations. Microsoft Research says that you can reduce your odds of being compromised by 99.9% by implementing MFA. It is a reliable mechanism with different great benefits against breaches involving stolen and weak passwords, which is the cause of 81% of hacks around the world. So we kept talking about the two aspects of judging how your authentication mechanism is, the security and the convenience. So if we plot a graph against security and convenience, this is something we get, like coming from the traditional ways of authenticating, which is like just using normal passwords, username and passwords, that is both low on security and convenience. If you add a second factor authentication to password, it slightly becomes higher in terms of security, but then it degrades in convenience because now the user has to go through multiple layers of authentication. So what the IT teams try to deliver is a seamless user experience while balancing the security risk. MFA is a great way to secure your organization, but user often get frustrated with the additional security layer on top of having to remember a password. And that's where the solution of passwordless authentication comes into picture. So passwordless authentication is both high on security and convenience. It not only provides convenient, easy to use and intuitive sign-in user experience, but also reduces helpless costs while meeting the needs of privacy and security. So what exactly is passwordless authentication? In this method, the password is simply removed and replaced with the other two factors of authenticating. That is something you have or something you are. So a very common example of this is biometric authentication, which is among other things now also available to log into Windows 10 device using a biometric gesture like face, recognition, fingerprint, et cetera, similar to the Apple's Face ID or Touch ID. Other examples of passwordless authentication include the push authentication, which basically converts your mobile device into an authenticating token. Again, something that you have locally. So Ipsha mentioned the use of biometrics as a form of password authentication. So let's look into it in more details. So basically biometrics is the most pertinent means of identifying and authenticating individuals in a reliable and very fast through the use of unique biological characteristics. Biometrics allows a person to be identified and authenticated based on a set of recognizable and verifiable data, which are unique and specific to that person. So basically there are two types of biometrics that we have. The first one is the physiological measurements and the second one is the behavioral measurements. So your physiological measurements, these mainly consist of your fingerprints, the shape of your hand or the finger, vein pattern, the eye, iris and retina scan, and the shape of your face, the morphological analysis. And in the behavioral, the most common are your voice recognition, signature dynamics, a speed of movement of pen, acceleration, the pressure exerted, exerted inclination, keystroke dynamics, the way we use objects, gate, the sound of steps, gestures, et cetera. So physiological measurements are usually offering the benefit of remaining more stable throughout the life of an individual. For example, they are not as subject to the effects of stress in contrast to the identification by behavioral measurements. The use of biometrics has many benefits. The leading one is the level of security and accuracy that it guarantees. In contrast to password, badges or documents, biometric data cannot be forgotten, exchanged, stolen or forged. And according to calculations made by Sir Francis Geltow, the probability of finding two similar fingerprints is one in 64 billion, even with the identical twins. Plus it has a bunch of use cases. So the first use case is law enforcement and public security, where biometrics can be used to identify criminals, suspects, et cetera. And the second one is in military, where you can use it for enemy and ally identification. The third one is border travel and migration control, where you can use it for the identification of traveler, migrant and passengers. The fourth one is civil identification, which is used for identifying citizens, residents and voter. And so on, you can use it in healthcare and subsidies, physical and commercial applications. So let's talk about the civil identification. So in India, the Adhaar project is by far the world's largest biometric identification system. So Adhaar's number is a 12 digit unique identity tree number issued to all Indian residents on their biographic and biometric data. A photograph, 10 fingerprints, two iris scans. And as of third January 2020, over 1.25 billion people have an Adhaar number, covering more than 99% of the Indian adult population. So how do we use the concept of biometrics in terms of authentication? So biometric authentication is a process of comparing data for the person's characteristic to the person's biometric template to determine resemblance. The reference model is first stored in a database or a secure portable element like a smart card. The data stored is then compared to the person's biometric data to be authenticated. Here it is the person's identity that is being verified. But biometric authentication relies on statistical algorithms. It therefore cannot be 100% reliable when used alone. The technical challenges of automated recognition of individuals based on their biological and behavioral characteristics are inherent to the transformation of analog, which is facial, image, fingerprints, voice patterns through digital informations like patterns that can then be processed, compared, and matched with the effective algorithms. Biometric suffers from the fact that the matching algorithm cannot be compared to the hashes of password, as we said. This means that two biometric measures cannot be compared with each other without them at some point being in plain text in the memory of the device doing the matching. Biometric checks must therefore be carried out on a trusted secure device, which means the alternatives are to have a centralized and supervised server, a trusted biometric device, or a personal security component. Biometric authentication has paved the way to introduce the number of new technologies, for example. So now there are smart ID cards. So numerous national identity cards in different countries like Portugal, Ecuador, South Africa, et cetera, now incorporate digital security features, which are based on the match-on-card fingerprint matching algorithm. Unlike conventional biometric process, the match-on-card algorithm allows fingerprints to be matched locally with a reference frame thanks to the microprocessor built into the biometric ID card and without having to connect to a central biometric database. The second one are the biometric sensor cards. The integration of a fingerprint scanner into smart cards is another form of delivering a safe and convenient way to authenticate people. These biometric sensor cards open up a new dimension in the identification with an ease-to-use, portable, and secure device. They have been launched in 2018 for the first time by the Bank of Cyprus and Gemalto for EVM cards, contactless, and contact payments. They use fingerprint recognition instead of a pin code to authenticate the card holder. The biometric identifiers are checked locally, protected, as they are stored solely on the card, they never leave the card. So that was all for biometrics. Now, while talking about passwordless authentication, we earlier mentioned that how Windows now allow you to log in to your device on Windows 10 using Windows Hello. So Windows Hello is basically a biometric-based technology that enables sign-in mechanism, essentially as an alternative to passwords. This is widely considered more user-friendly, secure, reliable method to access critical devices and services. So very quickly going through what a Windows Hello is, it is safe and secure sign-in mechanism. You can unlock your device using biometric gestures or a pin that is local to a device. And the data is stored locally and never leaves the device. So the biometric data doesn't roam anywhere and is never sent to any external device or server. Because Windows Hello store the biometric identification data on the device, there's no single collection point and attacker can compromise to steal data, as opposed to passwords which are shared secrets, entered and transmitted over network to servers. The intercepted username and password can be used anywhere by anyone since they are stored on the server in case a server breach happens. So authentication secured with a cryptographic key pair is the core concept of Windows Hello. The device creates a public, private key pair when registered. The private key can only be unlocked using a local gesture, such as the biometric or the pin, and then user can sign-in with biometric recognition that's unlocked and secured on the device. So when the identity provider supports key, basically Windows Hello provisioning process creates a crypto key pair which is bound to the TPM, that is the module that is installed in your device. And if it's not there, there are certain other software that can store the key pair. Now access to these keys and obtaining a signature to validate a user possession of the private key is enabled only by the pin or the biometric gesture. The two step that takes place during the Windows Hello enrollment creates a trust between the IDP and the user when the public portion of the key is sent to the IDP associated with the user account. So the server now has a public key that is mapped to the user account during the registration process itself. So then when a user enters a gesture, like a fingerprint or facial recognition on the device, the IDP knows from the combination of the Hello keys and the gesture that this is a verified identity and provides an authentication token that allows user to access resources and services. So as we discussed earlier, push authentication is a way of passwordless authentication. So basically push is a technology that verifies the identity of users by sending a push notification to a mobile device associated with their account during the login process, meaning that there is nothing to remember. All that needs to happen is for the device to be in the hands of the person who owns the account they are trying to access. In a sense, it turns the mobile device into an authentication token. This factor leverages a communication technology originally developed for smartphones, which today is popular in both iOS and Android environments. With this type of authentication, the user accepts or declines transactions, login request, and other operations by pressing a button on a pop-up notification on their smartphone. So basically how it works. So suppose a user wants to access any resource, so it's just a login to that resource and enter his user or her username, and press Enter. Then that application sends a push notification to the mobile device of that user that is being registered previously at the registration part. And when the push notification is sent to the user's mobile device, the user then can accept or deny whether it wants to allow the application to grant access or not. And on successful authentication, not successful authentication, the user is locked into the protected resource. So why we need push? So basically there is no need to memorize and manage passwords. Notification provides a seamless and user-friendly experience. When implemented properly, it is resistant to interception or redirection. That is, it is more secure. So basically if you are doing push authentications, it is very hard to intercept the message and by any hacker that is man in the middle attack. So that's why it is more secure in that manner. So we basically saw a different mechanism. Some were high on security and the others were very convenient for the end user. Some very new technologies are gaining momentum and replacing passwords. Moving from passwords to a stronger mechanism of authentication is indeed the greatest challenge present in today's computing world, but it is imperative in today's time. Since the risk possessed by hacking and breaches a serious and carries a significant real-world impact to businesses and users. The cost now overweighs the benefits of using passwords, predictable and vulnerable. Even though no change is easy and challenges follow as organizations proceed towards adopting password less authentication, the awards related to it are indeed very rewarding. From a technical point of view, the process of reducing and eliminating passwords altogether is the much required change. And as the urgency of making authentication safer and simpler increases, we see more tech come up devices that recognizes voice prints to unique heart rate and trend of wearable computing devices. And we would just like to end this talk by saying that the technology is already there and we just need to start adopting it. Thank you very much.