Defcon 15: "Strong" Authentication in Web Applications

Has your organization recently implemented multi-factor, risk-based, or mutual authentication? Do you think your application is now more secure and has a "strong" authentication system in place? Often, web applications are actually at more risk once these authentication features are introduced due to the considerable amount of complexity added. The typical result is to have implementation flaws that allow attackers to harvest usernames, obtain customers' mutual authentication images, or bypass security questions.

Until recently, there have not been many resources made available to the public about how to find and exploit vulnerabilities pertaining to these new authentication features; however Brendan O'Connor's presentation at Defcon 15 provided a great deal of visibility to these issues. His presentation, "Defeating Strong Authentication in Web Applications", discussed the common issues seen in these authentication systems and how to carry out associated attacks. O'Connor's presentation specifically discussed problems with mutual authentication, device fingerprinting, out of band authentication, one time passwords, and knowledge base archives. He highlighted technical flaws in the implementation of these features as well as reasons why the features may be inappropriate solutions to the problem an organization is trying to address.

A great example of how new risk is introduced by implementing these authentication systems can be found in the first step of many mutual authentication login processes. In the past, applications asked for the customer's username and password on a single page. If either of these credential pieces was incorrect, the application would respond with a generic authentication error which did not reveal whether the username or password was the incorrect piece.

Now that mutual authentication has been included in the mix, applications commonly ask for the customer's username ONLY as a first step. If that username does not exist, the application may display an error or behave in a completely different manner than if the username were valid. This is all happens before the application ever asks for a password, an answer to a security question, or a permanent cookie/flash object.

The added risk to the application is that an attacker can now discover one of the three secret credential pieces (for example: username, security question answer/permanent cookie, and password) needed to gain entry into the application. This reduces the "strong" authentication system's effectiveness to that of the simple username and password combination, in that only two credential pieces are needed to login.

So, is this a big deal? Do you think any hackers will test your organization's authentication system? There were around 7,000 attendees at this year's Defcon and all these attendees received a copy of O'Connor's slides. In addition, there were more than three hundred interested individuals who attended his presentation. Odds are there are many people who not only think this is a big deal, but are interested in whether your organization implemented their new "strong" authentication system securely. There are also many who may have the knowledge and expertise to find out for themselves if your web application has any of the flaws discussed in O'Connor's presentation.

My suggestion is if you haven't yet looked into these issues in your environment, you should start as soon as possible. Otherwise, someone else is going to find these authentication vulnerabilities and use them to compromise your customers' accounts.

To learn more about challenges and flaws introduced by implementing risk-based, multi-factor, or mutual authentication systems see the App Security Advisor Multi-Factor and Risk-Based Authentication podcast.