Article: Adaptive authentication explained

Dave Kearns

To understand what this newsletter is about it’s important that we have an agreement on what we mean when we use the term “adaptive authentication”. It isn’t a difficult concept, but it’s best if we’re all on the same page, so to speak.

First, the basics: authentication is the ceremony which allows someone to present credentials which allow access to something. Typically and traditionally this is a username/password combination. But username/password is only one facet of one factor of authentication and we usually speak of three possible factors, identified as:

• Something you know (e.g., a password)
• Something you have (e.g., a token such as a SecureID fob)
• Something you are (e.g., a biometric such as a fingerprint)

There are multiple facets to each of these, of course, such as the so-called There are multiple facets to each of these, of course, such as the so-called “security questions” (mother’s maiden name, first pet’s name, city you were born in, etc.) which are part of the Something you know factor.

Beginning around 30 years ago, it was suggested that multi-factor authentication – using two of the three factors, or even all three – made for stronger security. Within the last ten years, on-line organizations (such as financial businesses) and even social networks (Google+, Facebook, etc.) have suggested users move to two-factor authentication.

While this is good practice, this multi-factor authentication is static. Every time you access the service you need to present the same two credentials in order to log in. It’s always the same. Once a hacker (usually through what’s called “phishing”) knows the two factors your account is as open to them as if there was no security.

Within the past 5 years we sat KuppingerCole have advocated moving to what we called “dynamic” authentication – authentication that could change “on the fly”. But because we advocated much more than a change in how the authentication credentials were established, we now call the technology “adaptive” authentication.

It’s called “adaptive” because it adapts to the circumstances at the time of the authentication ceremony and dynamically adjusts both the authentication factors as well as the facet(s) of the factors chosen. This is all done as part of the risk analysis of what we call the Adaptive Policy-based Access Management (APAM) system. It’s best to show an example of how this works.

Let’s say that the CFO of a company wishes to access the company’s financial data from his desktop PC in his office on a Monday afternoon. The default authentication is a username, password and hardware token. The CFO presents these, and is granted full access. Now let’s say another CFO of another company wishes to access that company’s financial data. But she’s not in the office, so she’s using a computer at an internet café on a Caribbean island where she’s vacationing. The access control system notes the “new” hardware’s footprint, it’s previously unknown IP address and the general location. Based on these (and other) context data from the transaction the access control system asks for additional factors and facets for authentication, perhaps password, token, security questions and more. Even so, once the CFO presents these facets and factors she is only given limited read access to the data.

The authentication is dynamically changed and adapted to the circumstances. That’s what we’re discussing here. 

Comment: Why we need adaptive authentication everywhere – not just in eBanking

Matthias Reinwarth

Most probably the first thing that comes to your mind, when being asked about what should be highly secure when being done online is electronic banking. Your account data, your credit card transactions and all the various types of transactions that can be executed online today, ranging from simple status queries to complex brokerage, require adequate protection. With the criticality of the individual transactions varying substantially, this is also true for the required level of protection. This makes electronic banking the perfect use case for explaining and demonstrating adaptive authentication.

But creating an access matrix by mapping a set of client side attributes on one axis to a set of application functionality of varying criticality on the other axis makes perfect sense for almost any application available online as of today. The analysis of a user’s location, the time of day and the time zone, the operating system or browser type and the respective version of the used device is vital information for identifying heightened access risk. Cleverer context data might be derived from the number of consecutive failed login attempts and the actual time required for the successful login process (several failed attempts and then very fast login: might be an automated brute force attack). These mechanisms are incredible improvements for online privacy and security when defined and implemented appropriately.

Maybe the most important argument for having adaptive authentication in almost every other application as well might come as a surprise: It is ease of use. Many applications do provide certain functionalities that require strong authentication in general and certain other functionalities that should be protected adequately in case of inappropriate context information suggesting this. The majority of functionalities, however, is usually of lower criticality and should, as a result, be available without customers / citizens / members / subscribers/… having to provide strong authentication data, requiring for example two-factor-authentication.

• Many users log into their favourite shopping portals just for “research purposes” on a regular basis without actually buying something in that very session (i.e. the digital equivalent for going window shopping). As long as no purchase is made no additional adaptive authentication should be required in most cases.
• The same can apply for accessing basic functionality (e.g. read-only access to general information of the local municipality) within an eGovernment site. As long as no PII or other sensitive data is retrieved or even modified, a simple authentication on basis of username and a reasonably strong password should be sufficient.
• Watching a cartoon suitable for children on your favourite video streaming service might be fine using the usually already configured basic authentication, but the attempt to change the parental control settings obviously has to trigger a request for providing additional authentication.

But we are of course not only talking about end users accessing more or less public online services in different scenarios. In corporate environments, employees, partners and external workforce are accessing enterprise resources located on-premises or deployed in diverse cloud or hybrid infrastructures. With the ever changing landscape of user devices they will want to have access to corporate applications and services from various types of devices ranging from corporate notebooks to all types of personal devices, including mobile phones or tablets. Every organisation will have the ability to define their own policies, whether individual types of access is permitted in general and which rules apply for which type and criticality of functionality. The decision whether access can be provided at all or whether e.g. a step-up authentication is required can be made based on large set of available information at runtime. This information can include e.g. the general user group(employee, external workforce, partners, freelance sales partners and even customers), of course detailed identity data of the individual user, the accessing device (e.g. type, operating system, browser, versions), type and security of current network access (e.g. mobile access via cellular network, originating country, secured by VPN or not), local time and time zone and many many more. With all this information available at runtime it is clear that decisions for accessing the same resource for the same user can be different for a secured national connection from a corporate end-user device versus a connection from an outdated Android device originating from an untrusted country and without line encryption.

The above given examples clearly show the advantages of adaptive authentication in a lot of different use case scenarios: Adaptive authentication allows to provide both: a) An improved user experience by not requesting additional authentication whenever it is not required. And b) an adequate level of protection for user security and privacy whenever context information and/or the criticality of the requested functionality demand for that. Both are perfect reasons for you as either the provider of online services or being responsible for secure and modern corporate infrastructure components to consider implementing adaptive authentication soon.

• • 
    Dave Kearns

Weiterführende Links

• Originalmeldung von Kuppinger Cole Ltd.
• Alle Meldungen von Kuppinger Cole Ltd.