Let’s look at the work of the protocol in more detail.

The user enters a username and password. The server checks the credentials, and if they are correct, generates a random challenge and sends it to the client software, which, in turn, passes it to the U2F device. The U2F device waits for the user to take action for confirming further operations (as discussed above, pushing a button on the device), and then returns the signed challenge to the client software, which is passed on to the server to verify the signature.

To protect users against phishing, the client software adds the origin URL and TLS channel ID to the challenge before sending to the U2F device, while the server, after getting the signature, verifies the data received.

Signing everything with the same pair of keys will lead to a variety of negative results, from one account of a service getting compromised to all accounts using the U2F device compromised. In order to avoid this, during registration, together with the challenge, the server sends an application ID and random seed, based on which the U2F device generates a unique pair of Registering Dependent Keys. The method of generation is not described in the protocol and is fully at the discretion of the device manufacturer.

Due to the fact that the pair of keys is unique to each registration attempt, it is possible to use one device for multiple U2F accounts.

In order to protect the U2F device from cloning, the standard provides a built-in counter. Each signature and registration attempt increases the counter status by one measure. The counter status is signed and returned to the dependent party with the response. If the U2F device is cloned, then the state of the cloned device counter will be lower by one measure when compared to the counter state of the original device. This will cause an error during verification.

In order to avoid insecure implementations, each U2F device has a built-in certificate that guarantees specific hardware implementation of the device and is certified by the FIDO Alliance.

In a situation when the user is away from devices, malicious software may try to attack them. To avoid such scenarios, the U2F standard requires that all singing challenge operations are activated by the user (i.e., the user must confirm the decision to choose two-factor authentication). As mentioned above, this may be a simple push of a button, entering a PIN code, entering a fingerprint or using another unique identifier.

U2F Verdict

U2F is a well-designed, strong, open and standardized technology. It is implemented by such giants as Google, GitHub, Dropbox, and official British government websites.

It is important to remember that U2F, like any other two-factor authentication technology, must be used precisely as a secondary factor to the user’s login and password credentials.

FIDO U2F in Practice

Working with Services

To use a U2F token as a secondary factor when working with services supporting U2F authentication on a Linux machine, you have to meet only a few conditions.

Install a libu2f-host package, which contains udev-rules for the correct identification of a U2F token.

It should be clarified that the data of the udev rule applies only to tokens from Yubico. If your token is from another manufacturer, this file may be useful to you.

If you are an owner of the Blue FIDO U2F key, you also have to create a file called /etc/udev/rules.d/50-security-key.rules and add the following to it:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1050", OWNER="root", GROUP="plugdev", MODE:="0660"

After completing these actions, perform the following command:

udevadm control --reload-rules

You can check if udev is working correctly with this command:

 udevadm info -n /dev/usb/hiddev0 -a

For further work with services supporting U2F you will need Google Chrome, version 38 or higher.


To enable 2FA when you log in on a Linux machine, you will need to install a few extra packages:

  • hidapi (responsible for communication with USB tokens)
  • u2f-host (communication between the key and the server)
  • u2f-server (provides authentication to a U2F-host)
  • pam-u2f (PAM module for the U2F-server)

U2F Setup

To set up U2F you need to configure the file containing a list of your tokens, using the pamu2fcfg utility:

pamu2fcfg -u  > /etc/u2f_key_mapping_file

PAM Setup

Add the following at the end of file /etc/pam.d/common-auth:

auth       sufficient pam_u2f.so authfile=/etc/u2f_key_mapping_file cue

Note that the cue option directs you to a reminder console, urging you to press the button on the token. For more information about the pam_u2f module options, read this.

After the reboot and entering the login and password, your system will ask you to press a button on the token with the help of a message and the blinking of the key. Both sudo and su will work in the same way.

The sufficient option in the line above doesn’t require the presence of a U2F key.

If everything works smoothly, it can be substituted by required.

U2F Authentication Screen

Technically, with the help of manipulating PAM module configuration, you can also implement passwordless use, for example, su. After entering this command, you only need to click on the token button to confirm the action. But it is worth noting once again that you should use 2FA only for its intended purpose, namely as a secondary authentication factor.

Finally, the following are must-have conditions: the setup of full-disk encryption, setup of a BIOS password, and banning system boot from removable devices. Otherwise, 2FA will not prevent unauthorized data access if the attacker has physical access to the machine.

Maxim Sovetkin, lead system engineer, joined Itransition in 2010. His technical interests are in automation, hardware, *nix, networking, SAN, security, system integration, planning and design, virtualization, VoIP, wireless technologies, Windows and workforce management. Sovetkin graduated from Belarusian State University with a degree in mathematics, system analysis and IT systems modeling.

Photo courtesy of Shutterstock.