Add your answer..
I am sorry if this is a duplicate answer. I am a newbie.
I have been developing a platform that will support authentication with TOTP using Google Authenticator App, or OTP with Yubikeys, or FIDO U2F with compliant devices. I have evaluated 5 models of FIDO U2F devices, Yubikey Neo, Yubikey Security Device (Blue), ePass, HyperSecu and PlugUp.
Let me try to explain the security differences between TOTP, OTP and U2F. First, lets assume that the scenario is a website that wishes to authenticate it’s users with either a single factor that is more secure than username/password, or a second factor that extends the knowledge of the username/password with a second factor of possession of a security token. TOTP, OTP and U2F all provide a solution to this problem.
All 3 methods provide possession based user authentication based on a challenge/response model. A website that wants to authenticate it’s user generates a challenge value and presents it to the security device. The security device processes the challenge value and generates a response value that is unique for that device. The same challenge value presented to other devices will return unique response values for those devices. The uniqueness of the response from the security device is provided by a cryptographic key that is resident on the device. The response value is returned to the website where it is confirmed. If the confirmation is positive and other factors are positive, the user is granted access. The other factors would include checking if the device has not been reported lost or stolen and the user membership has not expired or been revoked.
Security of any challenge/response system is primarily achieved with proper management of the cryptographic key. All 3 methods involve a preliminary one time enrollment activity where the user links their login identity at the website with the security device in their possession. This is where the cryptographic key is created and shared between the user security device and the website database and is a point where the key value is vulnerable to disclosure. I will describe the differences in key management between the 3 methods. Once enrolled, the user security device can be used repeatedly in authentication dialogs.
TOTP – Time based One Time Password
TOTP uses the clock as the challenge value. In the case of Google Authenticator, the challenge value is the number of 30 second intervals since 1/1/1970. The cryptographic key is 80 bits in length and is created when the user enrolls for TOTP with the website. The website stores the TOTP key in it’s database as part of the user profile. Best practices would call for that key to be stored encrypted so that a data breach at the website would not reveal these keys unless of course the master key is also compromised. The website must now provide a method of transferring the user’s cryptographic key to their mobile devices. There are 2 ways this is typically done. A QR barcode is displayed on a webpage to the user as part of the enrollment on the website. The Google Authenticator app on the mobile device will read the barcode and securely store the key along with a label. If the mobile device cannot read the barcode, a 16 digit code can be displayed and entered manually. Only the GA app can retrieve and use the key. The GA app can store a virtually unlimited number of keys for different websites, identifiable with the label.
TOTP has the following vulnerabilities. (a) The challenge value is a simple counter and so if the users key is compromised, it is a trivial exercise to generate all the valid response values for that user into the future. (b) The cryptographic algorithm requires the key to be shared and it’s storage, retrieval and usage requires adequate protections. ( c) The crypto key is transferred to the mobile device during enrollment in the clear.
The Yubikey OTP uses a combination of counters, timers and random values to generate a random and non-predictive challenge value. The cryptographic key is 128 bits in length and is created by Yubico and stored directly on the device when it is manufactured. The key is then stored in their cloud verification service. The key never leaves the factory. Each Yubikey OTP also has a 12 byte unique identifier value that is returned as part of each OTP. The user interface is very simple. The Yubikey is inserted into the USB port and the user touches the device to generate the OTP. Enrollment simply requires the website to collect an OTP from the user, strip off the 12 byte identifier and then store that identifier as part of the user profile. Authentication requires the website to collect an OTP from the user, and use an API call to the Yubico cloud verification service to verify the OTP. This normally takes about 100 milliseconds. The Yubico service prevents replay and provides protection against man-in-the-middle and key logger attack scenarios.
Yubikey OTP provides excellent security for the website and eliminates all exposures to key management. The only vulnerability is the availability of the Yubico cloud verification service. Websites may provide for multiple Yubikeys to be enrolled by a user providing a simple backup solution. Self-service portals for enrollment and repudiation if lost can be implemented by the website.
FIDO U2F – Universal Second Factor
U2F uses a 256 bit random and non-predictive challenge value. The key management is based on Public Key Infrastructure (PKI). The user will have a unique public/private key pair for each website or service they enroll in for U2F authentication. FIDO U2F devices are used to create the key pairs and “store” all the private keys. Only the public keys are stored by the website. The U2F devices are USB compliant and are generally touch activated. Enrollment simply requires the U2F token to be inserted and touch activated. The device mints a key pair and returns a unique public key and key handle which are stored by the website linked to the user and a device name they select. Authentication of the user requires the website to generate a 32 character challenge value and present that along with the user key handle for the U2F device previously enrolled. The U2F device generates a digital signature with the private key within the secure element and returns the digital signature and an incrementing counter value. These 2 values are provided to the website which then validates the digital signature with the public key and validates the counter is incrementing properly.
U2F provides excellent security for the website and eliminates all exposures to key management. It also is not dependent on any cloud services. Websites may provide for multiple U2F devices to be enrolled by a user providing a simple backup solution. Self-service portals for enrollment and repudiation if lost can be implemented by the website. There are a couple of downsides to U2F solutions. First, the communication to the device on the USB port requires a browser extension and to date (April 2015), only Google Chrome version 38 and above has a U2F extension available. Second, the digital signature verification is not a trivial programming exercise. The correct cryptographic libraries must be used (ECDSA p-256) and there are subtle coding challenges when assembling the data to be signed.
I have successfully implemented all 3 of these methods for two factor authentication 2FA and I have developed .NET libraries to greatly simplify the development effort to adopt any or all of these as part of a authentication solution.