Why is it so Difficult to Add Two-Factor Authentication to Online Applications?
The primary challenge around adding two-factor authentication to online applications is that it is difficult to bolt-on anything to an existing product. The problem is usually unrelated to the security technology but is down to inherent problems with the web applications. Most are not designed with security in mind.
Traditionally, if access control was important, some kind of login functionality would have been added to the application. This has been the way since the early days of client-server model. Unfortunately not a lot has changed since then. Even the most cutting edge web applications are designed as a castle with a reinforced perimeter and a heavily guarded entrance in the form of the login page. Once in, all users will have access to everything they are authorized to.
The problem with this model is the assumption that everything behind the door has the same requirements for security, which is regularly not the case. Online banking applications recognized those challenges first, and understood the need to address them. They started by adding strong authentication to the function of authorizing money transfers. Following that, the U.S. federal government mandated two-factor authentication at login.
The web applications industry again, though, dodged the bullet by using the then new risk-based authentication model where only a low percentage of logins were considered risky enough (risk threshold is configurable by the banks) to warrant additional challenges. Thus, we know from experience that narrow specialization of applications allows bolting-on additional security measures later.
However, when the goal is to build a platform for providing solutions across multiple verticals, the access control has to be decentralized to provide just in time strong authentication and authorization. Security has to be built-in and available as a service to all modules of the application.
Rapid adoption of cloud-based services exacerbates the situation since the data and transactions that the login page protects are now subject to different security policies for different users. In other words, the same transaction or feature needs to be protected differently, depending on customer requirements. Customer requirements, whether it’s a private company or government organization, are difficult to predict when applications are initially designed.
Applications must be designed in a way that customers can apply the security requirements as configuration settings. An IntraLinks exchange is perfectly suited for this. Each exchange has its own ‘security level’ setting that can range from regular password to One Time Password (OTP) to any custom authentication mechanism. This kind of segmented application resolves the dual problem of strong authentication — appropriate level of security and user experience degradation. It enables customers to avoid putting the strongest authentication mechanism at login, which inconveniences all users, but at the entrance to their digital workspace (exchanges, in our case). Users will input a simple password to enter the application and see a list of exchanges that they are authorized to enter. They will seamlessly navigate to some exchanges. Some exchanges will ask for a security question. Others will challenge for an OTP. On top of that, if the customer has established a custom rule requiring that only internal IPs have access to the exchange, they may be declined access because the user Is not coming from an approved IP address.
This segmentation allows for extending security policies to the cloud. If the internal security policy requires two-factor authentication for a certain class of documents, an exchange can be configured for all documents of that class to be uploaded there. This will be particularly appealing to people who do not want to keep two systems — a cloud provider for data classified as, for example, ‘public’ and ‘unclassified’, and an internal system for ‘confidential’ documents.
In conclusion, the technology has matured to provide strong authentication for online applications and there is no good reason to not use it. With a little foresight in design phase, it is possible to introduce the strongest of electronic authentication mechanisms to the web.
I look forward to the deep dive into where and how to apply two-factor authentication, which I will be presenting at the RSA Conference in San Francisco next week.