Identity Management and Two-Factor Authentication Using One-Time Passwords

Two-factor authentication, or 2FA, is not something new. It has existed for quite some time and in different forms. What is a ‘factor’? A factor is something you have, something you know, or something you are. For example, if we combine a PIN that you know, with your fingerprint, we get a 2FA based on biometrics. In practice, biometric solutions are not often used because it's not especially difficult to steal someone’s fingerprint (...and it is quite hard to revoke or replace your finger). The more practical approach to two-factor authentication is to combine something you know, a PIN or password, with something you have.

Something you have often comes in form of

a device. It can be a device that you already have, for example a phone or tablet, or a device that is given to you, for example a smart card or a token. The device-based 2FA comes in two main flavors, namely: certificate based or one-time-password (OTP) based. The certificate based authentication leverages a smart card as a device. A smart card is effectively a password protected memory card with a secret (or secrets) stored on the it. You insert the card into a card reader and use your PIN to unlock the card. The PIN is used to decrypt the card's contents - allowing client side software (on the computer) to interact with the secret (or secrets) via a specific API.

An alternative to the smart card approach is OTP. This is a random password that is valid for a short period of time (usually 30 or 60 seconds). If you use a hardware token, a special device dedicated to generating the passwords (codes), the device will have a display that would show you a code. It is usually a numeric code of 6 or 8 digits (though different other devices exist). If you prefer to use an existing device (e.g. a phone) you can put an application on it that will generate a one time code for you to use for authentication. Such an application is called a “software token”. There are multiple vendors that build software token applications for mobile devices. The most well known one is Google Authenticator (GA). GA was built using open source and open source authentication standards – making it highly inter-operable and attractive to use. Unfortunately, Google made a decision to close source for Google Authenticator. Red Hat, being an open source company, decided to sponsor an alternative compatible open source implementation called FreeOTP. You can find this app in Apple App Store (here)  and in Google Play (here). What’s nice about FreeOTP being open source is that you have a direct contact to people behind the project. If you see an issue or a problem you can not only write a review but you can go one step further and interact with developers via a project list freeipa-devel@lists.fedorahosted.org and provide feedback as well as propose improvements.

The passwords (codes) that are generated by these tokens are random. But to be able to authenticate - the server should be able to generate the same code and be able to match it. To be able to do so the server, and the token, need to share the following factors:

• they need to support the same algorithm (i.e. the logic of how to generate the codes)
• they need to share the secret that is used as a seed for the random number generation algorithm
• they need to share some other factor that changes all the time... such a factor is usually either UTC time or a count of number of times the token has ever displayed a code

The tokens that use time are, unsurprisingly, called time-based tokens and the tokens that use count are called event-based tokens (because they display a code only when requested).

During the authentication the user combines their PIN (or password) with the code on the token and send it to the server. The server, knowing the PIN, seed, and time (or count) can generate the code it expects and will attempt to match this expected value to the data as entered by the user. As we don't live in a perfect world... there are times where the count or time gets out of sync. To compensate for such ‘drift’ the server generates more then one code. The number of codes it tries is usually configurable. This is called a token window. The bigger the window - the more codes the server will generate and try. This reduces the security of the solution so defining a wide window is generally a bad security practice. Sometimes the token gets out of sync so much that no codes match. In this case the user needs to re-synchronize the token by providing first the PIN and a code and then another code generated by his or her token. The server, in this case, determines the drift, records it, and factors it in next time the token is used.

An important step in preparing a 2FA solution is the provisioning of the tokens to users. During provisioning, the token seed on both sides is ensured to be the same. Software tokens are provisioned by generating a random code and passing it to the device the token will reside on. The hardware tokens are usually arrive pre-seeded so the seeds come in a data file and need to be loaded into the server. Some hardware tokens can be connected to the server and exchanged with server to establish a shared secret seed.

Identity Management and OTP

Starting with Red Hat Enterprise Linux 7.1 the Identity Management server is capable of performing two-factor authentication. This is the first commercially available domain controller that implements integration of 2FA with Kerberos. What does this mean? Previously, any integration between two-factor authentication and a domain controller required two steps: first, a user authenticated using his or her 2FA and then the user supplied password was used to authenticate and get a Kerberos ticket so that the user could take advantage of SSO between different services in a domain. The weak point of this solution is that there is always a single factor used to get a Kerberos ticket. IdM eliminates this problem by integrating 2FA into its Kerberos and LDAP services. Users can authenticate with two factors and get a Kerberos ticket as a result of such authentication in one step. The same authentication policies apply whether a user authenticates using Kerberos or LDAP.

In fact, IdM implements two variants of 2FA. The first variant leverages both hardware and software tokens managed within the IdM server. A user in IdM, by default, can authenticate using a single factor – their password. Administrators can enable a subset of users for OTP authentication. This means that a user in addition to his or her password would need to enter a token code from a token. Until there are no tokens assigned to the user the user will continue authenticating with their password, but once the user enrolls a hardware token or provisions a software token he or she would be required to provide both a password and a code as displayed on the token. Provisioning of a software token is initiated by a user via a self-service page. There is no limit on how many tokens can be added to the user but users must have at least one token until an administrator flips the switch and disables the OTP authentication requirement for this user. Such an approach allows a simple and smooth transition from a single factor authentication environment to 2FA without any extra overhead for users. In many cases administrators elect to setup self-service portals to allow a simple way to deploy software tokens to mobile devices. The user clicks a button and a QR code with token information is generated and displayed on their screen. This QR code can be scanned by the FreeOTP or GA application on their mobile device. Once scanned, the token will appear on your device. It is not recommended to try to use the same token from different devices as the QR code will not be displayed again. It is easy to delete the token and deploy it again or to add another token for another device.

Rounding out this exploration of 2FA - it is expected that IdM will be deployed in the environments where a 2FA is already provided by other vendors. In this case IdM can take advantage of the existing 2FA solution. All 2FA servers provide a capability to authenticate using the RADIUS protocol. IdM administrators can configure IdM as a client to one or more RADIUS servers. An authentication policy for a user can be set to use a specific RADIUS server. Once the policy is set to use RADIUS for a user, IdM would ignore user passwords or tokens and proxy user credentials to a particular RADIUS server. Once it gets the response from the RADIUS server, if authentication was successful, it will reply to its client with a Kerberos ticket. Otherwise it will deny user access. This proxy approach allows a simple and gradual migration from the 3^rd party solution to an IdM based solution. Such migration might be considered because of IdM’s unique Kerberos integration capability and the cost of the solution. 3^Rd party solutions are traditionally quite expensive. In case of Red Hat, FreeOTP is a free application and IdM is available free of charge as a part of your Red Hat Enterprise Linux subscription.

Cheers if you've read all the way to here - today's post was a long one.  That said, if there's something additional you'd like to learn about 2FA, IdM, one-time passwords, or anything else that was covered in this post - as always, don't hesitate to reach out.