PCI DSS requires two-factor authentication for remote access, to defend against password-guessing attacks.   Since nearly every organization takes credit cards, this requirement applies to nearly everyone.   This is an appropriate security standard whether the regulatory requirement applies or not.  Sophos Knowledgebase article 132629 speaks to the problem of password-guessing attacks from the Internet.  Similarly, my organization is also detecting and blocking password-guessing attacks on a regular basis.   Assuming that you have committed to using two-factor authentication, you have a choice of technologies.   The purpose of this document is to organize my thoughts and help others consider the  tradeoffs.

Security Control Points

Any two-factor security design needs to consider all three phases of credential management:

• Enrollment:   How to ensure that the 2-factor enrollment is given to the correct person.
• Login – How to validate that the login is from the correct person
• Termination – How to inactivate the account when it is no longer needed

Each of these will be addressed at appropriate points.

Remote User Populations

Your strategy may depend on the nature of your remote users, which I classify into these three groups:

• Employees, who will utilize whatever technology is required by company policy.
  The organization is aware of staff changes, so accounts can be created and terminated in a timely manner.
• Clients, who may change vendors if the chosen solution is perceived as odious.
  Although they can be trusted to request access when new staff desire access, they cannot be trusted to notify the organization when staff terminations occur.
• Consumers, some of whom will demand two-factor authentication, while others will reject any two-factor solution as too complicated.

I will assume that UTM is not be used for consumer populations, and is certainly outside my experience, so it is out of scope for the rest of this document.

Two-Factor Technologies

These are the known options for two-factor authentication

One-Step 2FA login using One-Time Password (OTP).

OTP is the 2-factor technology provided with UTM.   The UTM implementation is representative of similar one-step login systems based on OTP.

Key Strengths:

• OTP is free for as many users as UTM supports.
• All of the user information is collected at once, so an attacker obtains no information about the reason for a login failure.   UTM uses a single field for password and OTP, an attacker is not even notified that an OTP code was expected.
• A user can configure the OTP token on multiple devices.  
• OTP requires no network connectivity between UTM and the mobile device, which becomes important for foreign travel where cellular data usage can be very expensive.
• UTM WAF with OTP can provide a single login if the real webserver can be configured with Basic Authentication.
• The entire solution operates on UTM.

Key Weaknesses:

• UTM OTP requires a mobile device running the Authenticator application, so it provides no workaround for an employee that cannot carry a suitable device.
• Because it operates unconnected, the OTP issuer has no awareness, and no protection, if a 2-factor seed has been stolen.
• Because cell phones are replaced frequently, re-enrollment is an ongoing problem.   This problem can be avoided if people would use the old phone to enroll the new phone, but most users will not do so.  Instead, they will call the help desk to complain about being unable to log in.
• The UTM OTP can only be used for UTM logins.   Many third-party login systems integrate with RADIUS, TAKACS+, or LDAP services, but UTM cannot be used as a server for any of these technologies.
• Many implementations will require two logins, because the real webserver cannot be configured for Basic Authentication.  When this is the case, users will log into UTM first, then log into the real webserver.   Aside from user resistance, double logins create security concerns that will be addressed later.

Two-Step 2FA Login using DUO

DUO is a third-party product which has completed integration testing with UTM and as a result is approved by Sophos Support.     DUO is reasonable representative of all two-step authentication technologies.

Key Strengths:

• Can be used with a variety of confirmation methods:   Phone call, text message, or cell phone app.  A different authentication method can be requested for each login, depending on the flexibility allowed by organization policy.
• DUO operates as a RADIUS server.   If a product supports RADIUS authentication, the UTM login is not necessary because the real webserver can provide login with two-factor authentication.

Key Weaknesses

• The user must provide a valid username+password combination before the second step is initiated.   As a result, the password might be learned by password-guessing attacks.   Of course, if all remote access methods are protected by a two-factor process, the username and password do not provide enough information to obtain remote access.
• All of the second-step technologies require connectivity by phone or by cellular network.
• A monthly fee applies per user.  (DUO is free for sites with 10 or fewer users.)
• Second-step connectivity is performed by a cloud service.

Network Restrictions as a 2-Factor Technique

A third approach is to limit which login accounts can be used from which network addresses.

Key Strengths

• Restriction by source IP is effective when used for client connections, because terminated client staff automatically lose access when they lose access to the facility.
• Requires no per-user configuration.
• Requires no additional technology.
• Imposes no extra effort on the user

Key Weaknesses

• This approach only works when remote users are at a small number of fixed facilities, and those facilities have static internet addresses.
• This approach does not protect against password sharing or password theft within a facility.
• Requires a complex setup which may be difficult to implement and even more difficult to sustain.   The particulars of the setup will vary with each website.
• Because OTP is not enabled, the User Portal is not protected against password-guessing attacks.   Consequently, these users cannot be allowed access to the User Portal except on a closely monitored and temporary basis.

In an example project, this approach was used for an environment with a small number of clients operating from fixed locations.

• A wildcard certificate was obtained, and every client was given its own WAF site:  clientname-appname.example.com.  ( Note that wildcard domains are restricted to one level, so *.example.com cannot be used to protect clientname.appname.example.com)
• A Reverse Authentication profile was configured for each WAF site with an Allowed Users list containing the group representing the client’s users.
• A site path route was configured for each WAF site with access control enabled and restricted to the client’s source IP addresses, and linked to the client’s Reverse Authentication profile.

Other 2-Factor Techniques

There are other techniques as well, but I have not used them with UTM.   The ones that come to mind are:

• Personal Digital Certificates.   These are unlocked and activated with a certificate password, then used for login as an additional credential.
• Biometrics, such as fingerprint detection.

Typically, products like these would integrate with UTM as a RADIUS server, TAKACS+ server, or LDAP server.

Objections to Double Logins

Double Login refers to those situations where the 2FA login provides access past the perimeter firewall, but does not provide access to the target application or resource.   The user must complete a second login step to complete the desired connection.

When the login credentials are identical for both logins, users find the duplicated effort objectionable.   For security practitioners, the second login introduces the possibility that the second login will be attempted with a different username than the first.  If a password-guessing attack occurs at this point, accountability becomes very difficult.   Most second-level login tools will not collect enough data to link the failed application login to the successful remote login.

Consequently, any single-login solution is preferred over any double-login solution.

Logging and Notification Issues

The configuration options create these possible logging and notification use-cases:

• Single Login based on UTM2FA  login with transparent login to back-end resource.
• Single Login based on UTM bypass with 2FA login directly to back-end resource.
• Double Login based on UTM 2FA and back-end 1FA logins.

All of the solutions based on a UTM login will also have the protection of break-in evasion (account locked for X minutes after N failed logins) and immediate notification via email whenever breakin evasion is triggered.   Single-login solutions based on DUO RADIUS at the backend server are dependent on those subsystems to provide notification and breakin evasion.   Ideally, double-login solutions should have breakin evasion and notification at both login layers.   However, back-end solutions may have weak features related to breakin evasion and notification, and those limitations are often the reason that a front-end solution like UTM is required.

Remember that breakin evasion notices are not sufficient to detect all password guessing attacks.   A determined attacker will guess slowly and from different source addresses, to minimize the chance that a breakin evasion will be triggered.   After-the-fact log analysis needs to accompany real-time notification.

Initial Enrollment

The UTM Portal allows 1FA login until the 2FA login occurs for the first time.  The UTM Portal also must face the Internet to support its other functions, such as SSL VPN and HTML5 VPN.  This creates some risk that a compromised password can be used to create a rogue login with 2FA credentials.   To minimize this risk, these measures can be considered:

• OTP tokens are issued to users by IT staff, probably in person, using WebAdmin only.   User Portal is configured to not display OTP codes at all.
• Users should be enabled for remote access as close as possible to the time that they configure 2FA and login using the 2FA token.
• Breakin evasion notifications should be monitored closely to detect password-guessing attacks against the user portal.

Password Resets

A disadvantage of UTM authentication is that it does not support password expiration notices and password reset against remote authentication servers.   

The local authentication server also lacks desirable features, including:

• Account temporarily disabled
• Password must be reset at next login
• Password lifetime
• Password reset during WAF login
• Last password change date

 

OTP Resets

If your users are mostly authenticated using Active Directory or another backend service, an OTP reset can be handled by deleting the UTM local account for that person, as it will be recreated when the new OTP is used.   This is an inferior approach, as it leaves an orphaned OTP token, and it teaches bad habits that cannot be applied to local users.

The better way to reset OTP passwords is from Authentication Services... OTP.   The circular arrow "resets" the OTP, allowing the user to log back into the User Portal with just his password, so that he can display the OTP token.   It uses the same seed, so existing devices remain valid.   If the OTP token entry is deleted, all existing devices are invalidated, because a new seed will be generated when the user logs into the user portal.

If the user presents in person, the OTP code can be displayed from WebAdmin using the (i) button at the end of the token row.

 

Summary

Experts often observe that security has more to do with processes and procedures than with technology and products.  I think that is demonstrated by the issues discussed here.   There does not seem to be an obvious "best" technique for 2-factor authentication, but any of them can serve you well if you build the right human systems around the computer systems.

This thread was automatically locked due to age.