Integrating MFA into Legacy Web Sites

Two factor or multi-factor authentication is fast becoming a requirement for secure web applications. Simply offering a userid/password screen is no longer considered secure for many critical applications protecting sensitive data.

Companies and organizations that wish to protect customer-facing web sites with two-factor authentication face extra challenges including:

  • Users can be anyone with a large variety of devices/browser/tablets
  • Multi-factor products often charge by the user which is impractical with customer bases in 10s of thousands to millions
  • Users may live in areas where phone/messaging charges (for two factor code pushes) are very high
  • Adding the 2nd factor requires modification of existing code. This may not be possible due (e.g. commercial product, source code not available, etc.)

Let’s look at these challenges one at a time:

Customer devices

Unlike, employees, you are not in control of what devices users may have. This makes it near impossible to support any kind of device-based application that receives pushes. Ways around this include:

  • Avoid device software: instead push one-time codes to the phone with lowest-common denominator technology like emails and SMS pushes
  • Avoid devices altogether send one time codes with emails or dial phones and read codes via text-to-speech
  • Let someone else worry about it. For example Google Authenticator is an extremely popular one-time password generator that is well supported. You will still need an alternative (see above) for users without smart phones

Per-user charges

Cost control with a large and volatile customer base precludes per-user charges which are primarily meant for employee-facing multi-factor solutions. Alternatives include creating home-grown two-factor solutions perhaps using open-source technology like OpenOTP. Also look for providers with cost models independent of user counts.

Phone and SMS Tariffs

It can cost up to seven dollars to place a call or text to the Pitcairn Islands. Calls to mobile phones can also cost much more than to land lines. Your many not have many customer in the middle of the Pacific Ocean but pranksters/hackers can play havoc with your charges when your customer base consists of anyone who registers. The easiest way to avoid this is to avoid sending PIN codes via phone or SMS. Virtually all mobile devices have a email to SMS bridge which can be used instead. For example, emailing to 1234567890@txt.att.net will send an SMS text to the stated phone number. Other mechanisms such as time based one-time passwords (TOTP) like Google Authenticator do not require phone calls or text, however, they only work on smart phones.

Perhaps the largest, hidden cost of multi factor authentication is the integration into existing applications. Applications that previously prompted for user name and password, must be modified to now also ask for a second factor. For standard internal systems like Microsoft Windows or Unix terminals, most multi-factor vendors provide the required software, but for custom applications, it is usually left up to the customer.

Integrating into existing applications

Most two factor products have adapters can integrate into specific products such as Microsoft terminal servers or Linux server. But you are essentially on your own when it comes to integrating with web applications. This is because applications all work differently. Two factor products will come with API guides that will assist you in modifying your code but it will take development effort. If you do not have access to the source code or do not directly own the application, modification is not possible.

Options for dealing with legacy application include:

  • Web filters: both .Net and Java servlets have filter technology that allows each web request to be wrapped with some code that executes before the web request is handled. If your multi-factor product supports filters or you can write your own, you can attempt to intercept site requests and then re-direct to a secondary web site to prompt for 2nd factor credentials. In this scenario, it is essential to place both the main server and second factor server in the same domain to avoid popup warnings regarding cross-domain redirects issues.
  • Intelligent 2nd factor Proxy: Proxy servers are a good choice if you cannot modify the web server or application in any way. Similar to the filter, 2nd factor proxies intercept incoming web requests and detect if a 2nd factor is needed. They then prompt for the 2nd factor and only allow access through if the 2nd factor is successfully passed.

Note that both the filter and proxy solution require “2nd factor first”. This is where the second factor (pin number, secret question, etc.) is requested before the typical user name and password. This is a perfectly valid approach that many security administrator prefer since it prevents potential hackers from trying to guess the user password by seeing if the site passes them through to the 2nd factor screen.

Web application provide unique challenges to multi-factor authentication but can be secured effectively and economically by making strategic choices regarding products and authentication approaches.