How does FIDO work?
FIDO (Fast IDentity Online) Alliance was created in July 2012 to solve the problem of supporting strong authentication devices on the Internet, as well as to simplify the lives of users who are forced to create and remember usernames and passwords. FIDO Alliance plans to change the current situation with authentication by developing specifications that define a set of mechanisms that will supplant password dependencies and provide secure authentication for users of Internet services. The new standard for device and plug-in security for browsers will allow any website or cloud application to interact with a wide range of existing and promising devices to ensure secure user authentication.
To ensure the safe operation of users, the FIDO project combines hardware, software and Internet services.
If someone is not familiar with FIDO, the translation of the section of the site “How FIDO Works” is below. And now for a little comment.
Our team developed a solution for hardware authentication on web resources . The solution turned out to be quite successful, it is used in workflow systems and in SaaS licensing mechanisms. The technical part of the FIDO project is quite similar to our developments and looks quite doable. However, from the description on the FIDO website, it becomes clear that they do not yet have a clear understanding of what and how to do. And the concept itself raises a number of questions.
Security
The FIDO Alliance assumes the following authentication device distribution mechanism. At the production stage, the devices receive an identification number and a secret. This information is placed by the manufacturer in the FIDO Repository. When registering a new user, the service requests the device identification number and from this number receives from FIDO Repository the data necessary to verify the user during authentication. This data is cached by the Validation Cache web service to reduce the load on the FIDO Repository.
Unfortunately, nothing is said about the used cryptographic algorithms and protocols. However, by indirect indications (the term OTP is used in the text, as well as according to the scheme with the Repository), we can assume that it is planned to use symmetric algorithms. For me, this solution seems a bit outdated. The safe distribution of symmetric keys, which the Repository should apparently be doing, seems dubious. According to the logic of things, each device, when registering on a new Internet service, should generate a new key on its own. That is, for each service its own key and no global identification numbers. In addition, in order not to store any secret keys on the server, it seems reasonable to use asymmetric algorithms.
FIDO involves the use of two main types of devices for authentication. In their terminology, these are Identification tokens and Authentication tokens. The first option does not require owner authentication. That is, while the device is connected, authentication is transparent to the user. Undoubtedly convenient. However, anyone with access to the device can use this mechanism, for example, the wife will be able to read her husband’s correspondence. I think it’s impossible to refuse the second factor.
Privacy
Sadly, using a global identifier also allows you to build a connection between different accounts by device number, and not everyone will like it. Currently, there are serious problems with privacy on the Internet, and this approach also exacerbates this problem. It seems that there should not be any global identifiers, in general there is no need for them.
Restoring access
The concept does not say anything about the mechanisms of interaction in case of loss of a hardware device. A convenient and safe solution to this issue is very important, as it can cause a serious increase in the load on technical support.
PR
The solution will be obviously demanded by some of the users who conduct any commercial activity on the Internet. However, for the widespread, widespread use of strong authentication, it is necessary not only to ensure security, but also to offer a solution that will be convenient and fashionable. Popularization of the developed solution can become one of the most expensive parts of this project. In this regard, participation in this alliance of not only developers, but services such as PayPal and Google looks very encouraging.
And here is the translation.
FIDO Authenticators
Users will have a FIDO Authenticator or token ( any authentication hardware device that supports FIDO mechanisms - translator comment ), which they have selected, or which has been issued to them for using any service. For example, devices such as a biometric scanner or USB media with password access. Users can choose the type of FIDO Authenticator that best suits their requirements.
FIDO Authenticators will be issued in two main options.
Identification tokenswill have unique IDs, identifiers will be linked to the user's Internet account. After binding to the account, they will be available to the server as an identifier without the need for any action on the part of the user. Thus, only one authentication factor will be provided.
Authentication tokens may require the user to take some action to prove that he is the rightful owner of the token. These actions may include entering a password, entering a PIN, or providing biometric data. These authenticators will provide two-factor user authentication using the principle of “what you have” and “what you know” or the biometric factor “who you are”.
When a user connects his FIDO Authenticator to a web resource account, a connection is established between the Authenticator, the relying party and the Validation Cache. After creating a connection, one-time passwords (OTP) are used to verify the subscriber. Since the OTP password is used only once, it cannot be used for playback attacks if someone captures a session with an intrusion into the system or listens to Internet traffic.
Each authenticator will have a built-in ID and initial value that will allow uniquely identifying and verifying its authenticity. Cryptographic operations will occur on board the Authenticator. Thus, even if the machine is infected with malware, the FIDO Authenticator can still be trusted.
FIDO Plugin
User browsers will have a FIDO plugin. The plugin will be able to recognize the available FIDO Authenticators that are connected to the user's system. Including built-in authenticators and plug-in via USB.
When a user connects to a website, the browser will inform the server about the available FIDO Authenticators as part of the browser information. Sites that support FIDO technology will be able to recognize the authenticator and respond accordingly. Based on the information received, the relying party (website) initiates an authentication mechanism.
FIDO plugin can be distributed through various channels, including:
Browser Add-On - browser developers can have the plugin as an add-on that users can download and connect to their browser.
FIDO authenticators - If a user buys a FIDO authenticator with a built-in USB drive, the plug-in can be located on it.
Vendors - Vendors can distribute the plugin with new machines, and also include the plugin in the software updates for existing machines. These updates will enable FIDO authentication on existing machines with appropriate hardware capabilities.
Device Specific Module
A special device module (DSM) will interact with the browser plug-in on the one hand, and with the hardware FIDO Token on the other. DSM converts plugin commands to commands that are specific to each type of token. Dividing FIDO software into plug-in and DSM allows you to create a universal browser plug-in that supports a wide range of hardware devices. In addition, this will allow hardware solution providers to focus only on the development of the part of the software that is necessary to support their devices, and will not require the implementation of the entire software stack.
The relying party / Website
As the name implies, the relying party uses token verification for authentication.
The website recognizes the presence of the FIDO Token, determines whether it is tied to the account, and if not, provides the user with the opportunity to bind the new token to his account.
For example, having determined that the token is tied to an account, the website will add the message “Login with FIDO” to the login page. If the token has been identified as a fingerprint scanner, the message may be “swipe to enter with FIDO”.
Depending on the server policy, user preferences, and account history, Identification tokens can greatly simplify login. A website can simply identify an existing user and show "Welcome back Debbie!" Instead of the login window, based only on information from the FIDO token. Of course, the user will be able to change the login settings, determining for himself how dangerous this can be for his account.
Validation Cache
Validation Cache will check the encrypted information and one-time passwords received from the tokens to ensure the token is authentic.The relying party will use the Validation Cache to verify the information received from each token.
It is worth noting that the presence of Validation Cache on the site of the relying party will allow you to receive a response faster, to avoid delays in response or attacks. Validation Cache will regularly receive updates from the FIDO Repository about new devices produced by token providers.
FIDO Repository
FIDO Repository is a token information exchange center. Token makers will report each FIDO token generated in the Repository. The information stored in the Repository is used to check the OTP generated by the token. Repository will regularly update Validation Cache on every site that uses FIDO. Repository will support a large number of sites and have replication mechanisms to ensure uninterrupted service. A website will be able to use more than one Repository.
FIDO Repository will work with developers to ensure the relevance and availability of the token database. Using FIDO Repository will allow websites to not have contacts with each token provider. When connected to FIDO Repository, information about all existing tokens will be available to the web service.
Usage Examples
User Connection
When a user with a new token first goes to a site that supports FIDO technology, the site will suggest the user to attach the FIDO token to their account to increase security in the future. Information about the user's browser will inform the site that the user has a FIDO token, and will also tell the site the type of token. If the site supports FIDO, it will poll the token plugin in the background. Depending on the policy, the site will offer the user to connect a FIDO token to their account.
The procedure may vary depending on the type of User Authenticator, but all types will be supported through the same plugin.
Fingerprint scanner: user swipes the sensor. The authenticator performs crypto operations, the data goes to DSM, and then to the browser plug-in.
Password Protected Tokens : The user enters the correct password for the token.
Unique device identifier : Since this is not Authentication tokens, the user only needs to click OK to connect the identifier.
When the user agrees to connect the token and authenticates on it (if necessary), the global token ID and user ID are encrypted and sent back to the site. The site uses Validation Cache to verify the token. After checking the token, the site associates a unique token ID with the user account for future use.
User authentication
After the user has attached his Token to the account, he can use it instead of the login and password of the account. Below are three examples, but in the future, FIDO will support a wider range of FIDO tokens.
Fingerprint reader The
user goes to the website, his account is tied to a token with a fingerprint reader.
The browser informs the site that the user has a FIDO token with a fingerprint reader for authentication, the website presents the user with an authentication page option that supports FIDO. The website may show the message “Scan your finger to sign in with FIDO.” The user scans his fingerprints. FIDO token recognizes the user. User biometric data never leaves the reader. The global ID and authentication data is encrypted and sent back to the site through DSM and the plugin.
The site checks the received data through Validation Cache. The website identifies the user based on a globally unique identifier and user identifier. Thus, two-factor authentication is provided, since the presence of a token with a reader by the user is the first factor and the passage of biometric authentication is the second factor.
If a user used a token with a fingerprint reader with more than one account, the site will ask the user for the name of the account to which he wants to access.
Password Protected Tokens
The user goes to the website, his account is associated with a password-protected token. It can be a USB token or a module installed on the motherboard (TPM). The browser informs the site that the user has a FIDO token with a password, the website configures the authentication page using FIDO technology. The website may present the user with a “Click here for secure login with FIDO” message.
When the user clicks on the “FIDO Login” button, the plugin displays a local window (not a browser window) for entering the token password. This password is for local authentication in the FIDO token. This password is not accessible through a web browser and should only be transferred to a token.
The FIDO token authenticates the user. The global ID and authentication data is encrypted and sent back to the site through DSM and the plugin.
The site checks the received data through Validation Cache. The website identifies the user based on a globally unique identifier and user identifier. Thus, two-factor authentication is ensured, since the availability of a token by the user is the first factor, and knowledge of the password from the token is the second factor. If a user used a token with more than one account, the site will ask the user for the name of the account to which he wants to access.
Identifiers
The user goes to the website, his account is associated with the Identification token. This can be built-in hardware, additional software or hardware solutions that do not require knowledge of a PIN code or password, as they provide only identification. The browser tells the site that the user has an Identification token available for authentication. The website will ask the plugin for credentials. Data exchange with the server occurs in the background, without user interaction. The Global Identification Token ID is encrypted and sent back to the site through the DSM and plugin.
The site checks the received data through Validation Cache. The website identifies the user based on a globally unique identifier. If there is only one account associated with the identifier, then the user logs into his account without a password. This type of authentication is one-factor, since authentication requires only ownership of the identifier.
If the site policy requires two-factor authentication, then the user may be required to enter his password. As a second factor, without additional user interaction, the presence of an Identification token is checked.
New types of Authenticators
One of the goals of FIDO is to expand the range of devices. The intention is that all security devices that conform to the FIDO interface of the plugin should be accessible to all websites without changing the code. This will make it easy to connect new types of tokens to the system.
To add a new type of authentication, the developer must create a device, DSM and test it with the plugin. Then, the developer must transfer to the FIDO Repository the data necessary for testing new devices. Repository will ensure that data is available to all Validation Cache relying parties.
When a new authenticator appears on the site for the first time, the site will verify the authenticator using Validation Cache. The website may ask the user to perform any additional steps to authenticate the user, without knowing the details of these actions, since the interaction occurs through the plugin and DSM. When the user performs the necessary actions, the credentials will be connected to the user account.
To ensure the safe operation of users, the FIDO project combines hardware, software and Internet services.
If someone is not familiar with FIDO, the translation of the section of the site “How FIDO Works” is below. And now for a little comment.
Our team developed a solution for hardware authentication on web resources . The solution turned out to be quite successful, it is used in workflow systems and in SaaS licensing mechanisms. The technical part of the FIDO project is quite similar to our developments and looks quite doable. However, from the description on the FIDO website, it becomes clear that they do not yet have a clear understanding of what and how to do. And the concept itself raises a number of questions.
Security
The FIDO Alliance assumes the following authentication device distribution mechanism. At the production stage, the devices receive an identification number and a secret. This information is placed by the manufacturer in the FIDO Repository. When registering a new user, the service requests the device identification number and from this number receives from FIDO Repository the data necessary to verify the user during authentication. This data is cached by the Validation Cache web service to reduce the load on the FIDO Repository.
Unfortunately, nothing is said about the used cryptographic algorithms and protocols. However, by indirect indications (the term OTP is used in the text, as well as according to the scheme with the Repository), we can assume that it is planned to use symmetric algorithms. For me, this solution seems a bit outdated. The safe distribution of symmetric keys, which the Repository should apparently be doing, seems dubious. According to the logic of things, each device, when registering on a new Internet service, should generate a new key on its own. That is, for each service its own key and no global identification numbers. In addition, in order not to store any secret keys on the server, it seems reasonable to use asymmetric algorithms.
FIDO involves the use of two main types of devices for authentication. In their terminology, these are Identification tokens and Authentication tokens. The first option does not require owner authentication. That is, while the device is connected, authentication is transparent to the user. Undoubtedly convenient. However, anyone with access to the device can use this mechanism, for example, the wife will be able to read her husband’s correspondence. I think it’s impossible to refuse the second factor.
Privacy
Sadly, using a global identifier also allows you to build a connection between different accounts by device number, and not everyone will like it. Currently, there are serious problems with privacy on the Internet, and this approach also exacerbates this problem. It seems that there should not be any global identifiers, in general there is no need for them.
Restoring access
The concept does not say anything about the mechanisms of interaction in case of loss of a hardware device. A convenient and safe solution to this issue is very important, as it can cause a serious increase in the load on technical support.
PR
The solution will be obviously demanded by some of the users who conduct any commercial activity on the Internet. However, for the widespread, widespread use of strong authentication, it is necessary not only to ensure security, but also to offer a solution that will be convenient and fashionable. Popularization of the developed solution can become one of the most expensive parts of this project. In this regard, participation in this alliance of not only developers, but services such as PayPal and Google looks very encouraging.
And here is the translation.
How does FIDO work?
FIDO Authenticators
Users will have a FIDO Authenticator or token ( any authentication hardware device that supports FIDO mechanisms - translator comment ), which they have selected, or which has been issued to them for using any service. For example, devices such as a biometric scanner or USB media with password access. Users can choose the type of FIDO Authenticator that best suits their requirements.
FIDO Authenticators will be issued in two main options.
Identification tokenswill have unique IDs, identifiers will be linked to the user's Internet account. After binding to the account, they will be available to the server as an identifier without the need for any action on the part of the user. Thus, only one authentication factor will be provided.
Authentication tokens may require the user to take some action to prove that he is the rightful owner of the token. These actions may include entering a password, entering a PIN, or providing biometric data. These authenticators will provide two-factor user authentication using the principle of “what you have” and “what you know” or the biometric factor “who you are”.
When a user connects his FIDO Authenticator to a web resource account, a connection is established between the Authenticator, the relying party and the Validation Cache. After creating a connection, one-time passwords (OTP) are used to verify the subscriber. Since the OTP password is used only once, it cannot be used for playback attacks if someone captures a session with an intrusion into the system or listens to Internet traffic.
Each authenticator will have a built-in ID and initial value that will allow uniquely identifying and verifying its authenticity. Cryptographic operations will occur on board the Authenticator. Thus, even if the machine is infected with malware, the FIDO Authenticator can still be trusted.
FIDO Plugin
User browsers will have a FIDO plugin. The plugin will be able to recognize the available FIDO Authenticators that are connected to the user's system. Including built-in authenticators and plug-in via USB.
When a user connects to a website, the browser will inform the server about the available FIDO Authenticators as part of the browser information. Sites that support FIDO technology will be able to recognize the authenticator and respond accordingly. Based on the information received, the relying party (website) initiates an authentication mechanism.
FIDO plugin can be distributed through various channels, including:
Browser Add-On - browser developers can have the plugin as an add-on that users can download and connect to their browser.
FIDO authenticators - If a user buys a FIDO authenticator with a built-in USB drive, the plug-in can be located on it.
Vendors - Vendors can distribute the plugin with new machines, and also include the plugin in the software updates for existing machines. These updates will enable FIDO authentication on existing machines with appropriate hardware capabilities.
Device Specific Module
A special device module (DSM) will interact with the browser plug-in on the one hand, and with the hardware FIDO Token on the other. DSM converts plugin commands to commands that are specific to each type of token. Dividing FIDO software into plug-in and DSM allows you to create a universal browser plug-in that supports a wide range of hardware devices. In addition, this will allow hardware solution providers to focus only on the development of the part of the software that is necessary to support their devices, and will not require the implementation of the entire software stack.
The relying party / Website
As the name implies, the relying party uses token verification for authentication.
The website recognizes the presence of the FIDO Token, determines whether it is tied to the account, and if not, provides the user with the opportunity to bind the new token to his account.
For example, having determined that the token is tied to an account, the website will add the message “Login with FIDO” to the login page. If the token has been identified as a fingerprint scanner, the message may be “swipe to enter with FIDO”.
Depending on the server policy, user preferences, and account history, Identification tokens can greatly simplify login. A website can simply identify an existing user and show "Welcome back Debbie!" Instead of the login window, based only on information from the FIDO token. Of course, the user will be able to change the login settings, determining for himself how dangerous this can be for his account.
Validation Cache
Validation Cache will check the encrypted information and one-time passwords received from the tokens to ensure the token is authentic.The relying party will use the Validation Cache to verify the information received from each token.
It is worth noting that the presence of Validation Cache on the site of the relying party will allow you to receive a response faster, to avoid delays in response or attacks. Validation Cache will regularly receive updates from the FIDO Repository about new devices produced by token providers.
FIDO Repository
FIDO Repository is a token information exchange center. Token makers will report each FIDO token generated in the Repository. The information stored in the Repository is used to check the OTP generated by the token. Repository will regularly update Validation Cache on every site that uses FIDO. Repository will support a large number of sites and have replication mechanisms to ensure uninterrupted service. A website will be able to use more than one Repository.
FIDO Repository will work with developers to ensure the relevance and availability of the token database. Using FIDO Repository will allow websites to not have contacts with each token provider. When connected to FIDO Repository, information about all existing tokens will be available to the web service.
Usage Examples
User Connection
When a user with a new token first goes to a site that supports FIDO technology, the site will suggest the user to attach the FIDO token to their account to increase security in the future. Information about the user's browser will inform the site that the user has a FIDO token, and will also tell the site the type of token. If the site supports FIDO, it will poll the token plugin in the background. Depending on the policy, the site will offer the user to connect a FIDO token to their account.
The procedure may vary depending on the type of User Authenticator, but all types will be supported through the same plugin.
Fingerprint scanner: user swipes the sensor. The authenticator performs crypto operations, the data goes to DSM, and then to the browser plug-in.
Password Protected Tokens : The user enters the correct password for the token.
Unique device identifier : Since this is not Authentication tokens, the user only needs to click OK to connect the identifier.
When the user agrees to connect the token and authenticates on it (if necessary), the global token ID and user ID are encrypted and sent back to the site. The site uses Validation Cache to verify the token. After checking the token, the site associates a unique token ID with the user account for future use.
User authentication
After the user has attached his Token to the account, he can use it instead of the login and password of the account. Below are three examples, but in the future, FIDO will support a wider range of FIDO tokens.
Fingerprint reader The
user goes to the website, his account is tied to a token with a fingerprint reader.
The browser informs the site that the user has a FIDO token with a fingerprint reader for authentication, the website presents the user with an authentication page option that supports FIDO. The website may show the message “Scan your finger to sign in with FIDO.” The user scans his fingerprints. FIDO token recognizes the user. User biometric data never leaves the reader. The global ID and authentication data is encrypted and sent back to the site through DSM and the plugin.
The site checks the received data through Validation Cache. The website identifies the user based on a globally unique identifier and user identifier. Thus, two-factor authentication is provided, since the presence of a token with a reader by the user is the first factor and the passage of biometric authentication is the second factor.
If a user used a token with a fingerprint reader with more than one account, the site will ask the user for the name of the account to which he wants to access.
Password Protected Tokens
The user goes to the website, his account is associated with a password-protected token. It can be a USB token or a module installed on the motherboard (TPM). The browser informs the site that the user has a FIDO token with a password, the website configures the authentication page using FIDO technology. The website may present the user with a “Click here for secure login with FIDO” message.
When the user clicks on the “FIDO Login” button, the plugin displays a local window (not a browser window) for entering the token password. This password is for local authentication in the FIDO token. This password is not accessible through a web browser and should only be transferred to a token.
The FIDO token authenticates the user. The global ID and authentication data is encrypted and sent back to the site through DSM and the plugin.
The site checks the received data through Validation Cache. The website identifies the user based on a globally unique identifier and user identifier. Thus, two-factor authentication is ensured, since the availability of a token by the user is the first factor, and knowledge of the password from the token is the second factor. If a user used a token with more than one account, the site will ask the user for the name of the account to which he wants to access.
Identifiers
The user goes to the website, his account is associated with the Identification token. This can be built-in hardware, additional software or hardware solutions that do not require knowledge of a PIN code or password, as they provide only identification. The browser tells the site that the user has an Identification token available for authentication. The website will ask the plugin for credentials. Data exchange with the server occurs in the background, without user interaction. The Global Identification Token ID is encrypted and sent back to the site through the DSM and plugin.
The site checks the received data through Validation Cache. The website identifies the user based on a globally unique identifier. If there is only one account associated with the identifier, then the user logs into his account without a password. This type of authentication is one-factor, since authentication requires only ownership of the identifier.
If the site policy requires two-factor authentication, then the user may be required to enter his password. As a second factor, without additional user interaction, the presence of an Identification token is checked.
New types of Authenticators
One of the goals of FIDO is to expand the range of devices. The intention is that all security devices that conform to the FIDO interface of the plugin should be accessible to all websites without changing the code. This will make it easy to connect new types of tokens to the system.
To add a new type of authentication, the developer must create a device, DSM and test it with the plugin. Then, the developer must transfer to the FIDO Repository the data necessary for testing new devices. Repository will ensure that data is available to all Validation Cache relying parties.
When a new authenticator appears on the site for the first time, the site will verify the authenticator using Validation Cache. The website may ask the user to perform any additional steps to authenticate the user, without knowing the details of these actions, since the interaction occurs through the plugin and DSM. When the user performs the necessary actions, the credentials will be connected to the user account.