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 3rd 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. 3Rd 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.

  1. Hi Dmitri,

    Do you know if there is a way to have different authentication methods for different hosts with IDM? I would like to have some hosts use two factor authentication and others use single password.

    I have found how to change the authentication methods for each user but have not found how to do it based on host. Any help would be appreciated.

    -Troy

    1. For now you can configure SSSD with LDAP for password only cases and SSSD with Kerberos for 2FA. See documentation about the different of 1FA vs 2FA via LDAP vs. Kerberos.
      This is not best separation but it is what we have right now. We are looking at addressing this feature gap in the future releases.

      Thanks
      Dmitri

  2. Hi Dmitri,

    Sorry to keep bothering you. When using a radius server, is it possible to have the primary password authenticated through IDM and the secondary processed by the radius server?

    As an example, if a users password is ‘password’ and their auto generated passcode is 123456, is it possible to have IDM authenticate ‘password’ and the radius server authenticate 123456?

    We are attempting to setup IDM and want to use two factor authentication with a Duo radius server.

    -Troy

    1. Hello,

      There are huge challenges with this approach in general. If the password and code concatenated on the client side into a single string there is no general algorithm to split them back on the server side. This is a general problem regardless of the protocol or server implementation. The client needs to be smart and prompt separately but send both portions together in one requests but as two separate strings. I do not think it is possible with any client software except SSSD in RHEL 7.2. It is always a single prompt for user to provide a single string.
      But I am not sure why would you want to do it this way. You need to take a deeper look ad DUO and how it works. Based on a very quick scan it seems that making IdM as back end to DUO in the same way as with AD might be the option to explore.

      Thanks
      Dmitri

  3. I need to integrate IPA 7.2 server with Radius 2FA using Vasco hardware token. Please share the document or a link to do the same.

      1. Hi Dmitri,

        The link you provided is redirecting me on “Enabling Custom Home Directories ” link. Please share the correct link.

      2. It seems that there is some kind of bug in a documentation site. If you click the link it would open documentation in the wrong place but if you then go to the address line and hit enter again it will find the right anchor on the page. Anyway the section you need is 2.3.5.

        Thanks
        Dmitri

  4. Hello,
    it’s possible to activate 2FA when the user is not on trusted network. Having only the use the single password on friends networks and use 2FA on networks with lower confidence.

    Thanks

    1. Hello,

      It is somewhat possible but probably not exactly the way you would want it to be possible. We are looking to correct this limitation soon.
      Right now when you configure different methods at the same time for the same account i.e. single factor and two factor you get different behaviour over Kerberos and LDAP protocols. Kerberos will require 2FA in this case while LDAP would allow just password so you can configure trusted networks to use LDAP and untrusted use Kerberos. Getting back to the point at the beginning you would probably prefer the reverse i.e. to allow SSO with Kerberos on the trusted network using single factor and require 2FA on untrusted network probably without SSO using LDAP. This is not possible yet.

      See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index.html#otp for more details.

      Thanks
      Dmitri

    1. The solution allows you to proxy authentication via RADIUS to RSA Authentication Manager.
      So yes it supports it. User enters RSA PIN+token code, it does to IdM server, IdM server talks RADIUS to RSA, RSA authenticates and replies, user is issued a Kerberos ticket.
      Please check documentation for more details about capabilities and limitations of this solution.

    2. As Dmitri states, the IDM solution allows RADIUS authentication which will help a lot if you have unsupported second-factor needs or if you already have a two-factor solution in place. One thing to be aware of if implementing IDM with RADIUS, it will only work on RHEL 7.* clients and newer (as far as we have experienced) due to missing sssd functionality. One way around this issue is to install pam_radius to go directly to your RADIUS server during authentication (https://access.redhat.com/solutions/26165). Note that this method will not be supported by Red Hat. Kerberos tickets will not be issued on clients that authenticate using pam_radius but so far it is the best approach I have found around this issue.

  5. Dear Dmitri,

    I agree with the poster who said that IdM has matured nicely. I am amazed at what RH has accomplished in just few years. I would not be surprised if RHEL IdM would become wildly popular. Especially since the old sssd and AD interoperability in 5 and 6 (no realmd) are going away over time.

    I will probably design our IDM overhaul to use IdM for our RHEL servers with a trust to an AD domain for Windows servers. With AD containing nothing except service and machine accounts. But I do not see any easy way for SSO across the servers when using 2FA, especially the enhanced 7.2 flavor. Our admin stations would be Windows on a third domain that is separate from production.

    Do you have any plans to work with third party Kerberos client/identity managers (e.g. Network Identity Manager) to get such improved 2FA/SSO support for Windows?

    1. We have different plans to address the use case when admin is a Windows user and has his password in AD but needs to have a 2FA authentication against a Linux box connecting from a Windows machine. This is in fact an important use case that we are tracking. In the next upstream release, that hopefully will land in RHEL 7.3, we are laying down the foundation for this capability to happen in the follow up release. So far we have some ideas how to solve the problem without pushing all Kerberos vendors to adopt something new.

    1. Is there a specific information you are looking for?
      Please see a later article about RHEL 7.3 features. It consists of two parts.
      In 7.3 you now can centrally enforce which systems and service require 2FA.

      1. Hi!

        Which 2FA open source providers would you recommend me to check out? We would love to see a RH solution in this regard so we wouldn’t have to go look anywhere else, with the risk of that project being discontinued, etc.

        Thanks,

      2. For software tokens on the phone iOS/Android we recommend FreeOTP which is free and supported by Red Hat. For hardware tokens we recommend Yubikeys or any other vendor that supports TOTP and HOTP tokens.

        Thanks
        Dmitri

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s