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.

What OWASP is and what it means to you

Our blog has featured a link to the OWASP web site for most of its existence. Maybe you have clicked on it and checked out the great resources that OWASP has to offer. Maybe you already know about the organization and its ongoing projects. If you aren't familiar with OWASP, let me give you a quick introduction.

The Open Web Application Security Project (OWASP) is a not-for-profit group dedicated to improving the security of web applications. They support this goal by publishing security testing and software development guidance, creating web application security testing tools, and funding related projects that benefit the community.

OWASP also encourages the creation of local chapters where security professionals and developers can meet with their peers to exchange information. These chapter meetings typically include one or more presentations covering topics like web app attacks, security testing techniques and tools, secure coding practices, and product evaluations. Meetings also serve as a good opportunity to compare notes with other locals on what is going on with web app security in their organizations.

I recently had the honor of assuming leadership of the Kansas City OWASP chapter and am excited about the chance to spread knowledge of web application security in our area. However, I can’t accomplish this goal without your help. Right now our chapter mailing list only includes a few dozen of the hundreds of Kansas City professionals who would probably want to participate in this group.

If you or others in your organization aren’t currently subscribed, I encourage you to join today. If you have friends or former coworkers at other businesses, let them know about the chapter. Subscribing to our mailing list will keep you informed about the interesting topics that will be covered at upcoming meetings.

Our next meeting is September 6th and features a presentation from a federal bank examiner about the good and bad application security practices he’s observed at financial institutions. Get the location and time at our chapter website. I hope to see you there.

Defcon 2007

The Security PS consulting team recently attended Defcon 15. With five tracks running over three days, the conference jam-packed enough hacking techniques, exploits, and security news into our heads that I’m afraid I may have blown a fuse from information overload. The presentations covered everything from Wifi attacks to application security to hardware hacking, and speakers like Bruce Schneier, Johnny Long, and Dan Kaminsky didn’t disappoint packed audiences.

When one of your job requirements is keeping up with an entire world full of blackhat hackers, it’s helpful that once a year they all get together and tell you what they’re up to. We will be posting highlights from various talks over the next few weeks. Stay tuned.

Banks fail to meet FFIEC multi-factor authentication requirements

By the end of 2006, U.S. financial institutions were told to comply with the FFIEC’s updated guidance on authentication for Internet banking. This guidance instructed financial institutions to use multi-factor authentication, along with other security controls, for any online applications that allowed "high risk" transactions. Consequently, banks, credit unions, and other organizations hustled to integrate new authentication solutions that could satisfy bank examiners and reduce online fraud.

Did they succeed? One recently published study says no. In a paper titled Trends in U.S. Multi-factor Non-Compliance, Sestus Data Company and BearingPoint Financial Services report that only 4% of the 100 banks sampled consistently required multi-factor authentication. If this sample is representative of all U.S. financial institutions, and I feel fairly comfortable that it is, we appear to have a serious problem.

The main reason for the failing grade comes from conflicting interpretations of the term "multi-factor authentication". As the report points out, 90% of financial institutions have implemented additional authentication requirements in the form of challenge questions. However the FFIEC’s original guidance and subsequent FAQ explicitly require multi-factor authentication solutions to combine at least two of the three authentication factor types: what you know, what you have, and what you are. Combining challenge questions with passwords only builds upon the single factor category of 'what you know'.

So, the big question then becomes why are bank examiners are allowing financial institutions to get away with solutions that don’t meet the defined criteria. Just to be clear, I haven’t heard any official answer to this so I can only share my theories.

The new FFIEC authentication guidance was a pretty big shock to the many financial institutions who had given limited attention to their online application security. I can tell you from experience that some of these organizations were failing to establish and enforce even basic password requirements for customers.

Many financial institutions undoubtedly raised objections when they were told to skip the step of improving passwords altogether and jump directly to implementing multi-factor authentication. Especially when this jump meant investing around $15 - $30 per user before the 2007 deadline. Some of these organizations were tempted to find lower cost solutions that would address some of the FFIEC’s concerns about authentication attacks.

At this point bank examiners could have sat down with the financial institutions and told them that these changes were inadequate. Astonishingly, I haven’t seen or heard anything to indicate that these conversations ever took place.

Maybe bank examiners are at odds with the FFIEC personnel who pushed the requirements for true multi-factor authentication. Maybe they are willing to allow partial compliance with the guidance to see if these stopgap solutions still reduce fraud. They could still come back later and tell banks that they need to improve the ineffective authentication solutions. Maybe the examiners decided too late that the requirements were too drastic and are quietly allowing compromises by financial institutions so the FFIEC can save face.

Regardless of the motive, I don’t like the result. The financial institutions who took the guidance literally are now at a competitive disadvantage to those who didn’t. They probably have better authentication security but they are also likely to have spent more money on a multi-factor authentication solution. People don’t always like what’s good for them, especially when it includes a significant change, and a stronger authentication system may drive some customers to a competitor who has laxer security standards.

This is the wrong message for the government to send to financial institutions and consumers. Financial institutions may drag their feed in complying with any future security requirements until they find out what examiners will really require of them. Both customers and financial institutions will remain exposed to threats longer than necessary during this waiting process.

If you would like to share your perspectives on compliance with the FFIEC’s multi-factor authentication guidance, leave a comment. I’d love to hear your thoughts.