The 4th Factor? - 3 Factors of Fail (part 5)

   Welcome to the next installment of my ramblings on authentication, 3 Factors of Fail.  So far we have discussed the classic 3 factors of authentication in parts 1, 2, 3 and 4.

   In recent years some additional authentication assurance methods have been grouped to form what some call the 4th factor of authentication.  This is also called risk-based, location-based or adaptive authentication.  It could also be called "somewhere you are" or "something you are doing".

   The basis of this method is in establishing a rich profile of the user.  This can include:

• the machine used for access;
• software used;
• time or day of accesses;
• IP address(es) used;
• what country the connection comes from, or;
• what actions the user attempts.

   When a user attempts to connect, authenticate or perform certain transactions, these are compared to the users' profile.  In general, the use situation is checked against the profile, then access is either denied, allowed, or deferred to further layers of authentication.  The deferral could be based on a risk score calculated from the factors listed above.

   One example of this is in use with some financial institutions and personal banking.  First the connecting machine is authenticated, typically via MAC address.  Then the user must pick a preselected word, phrase or picture from a presented list.  If these barriers are passed then the user is prompted for their userid and password.  If an unusual transaction is requested, such as a large balance transfer, an additional challenge/response may be presented.

   One challenge in risk-based authentication, similar to biometrics, is registration or establishing an initial profile.  Often this can't happen until a sufficient number of connections and/or transactions have been completed.  The profile can also be based on other information the institution has about the user.

   And that's the catch... establishing a valid profile is not trivial.  It usually takes time to collect enough information to create a valid profile.  And there can be enough variability to make risk scoring difficult.  And if an acceptable risk level can't be established, the user is either denied access, defaults to userid and password, or get redirected to a help desk or other password bypass method.

   So, like all the factors of authentication we've discussed so far, the 4th factor has deficiencies.  In some cases the problem can degenerate into something you know (forgot).  Just because an organization has information about a user, does not mean the user can recall the information when prompted.  For example, a financial institution might ask a user attempting a large transaction to provide information about previous transactions or other accounts.  Of course, the user may or may not be able to recall that information.

   This is a newer set of methods and works best as a supplement to one of the other factors.  It still needs refinement.


   Do you have experience with risk-based or situation-based authentication?  How are you using this in your organization?

   I had originally intended this to be a 5-part series, but this is part 5 and I still have more to say!  Next time I will cover multi-factor authentication.