September 30th, 2013

Workshops, Workshops, Workshops!

Layer 7 API WorkshopsOne of the great things about my job is that I get to travel around the world sharing API design strategies, experiences and theories with people who are at the forefront of our industry. These interactions not only make it easier to design effective APIs, they also have the potential to spark ideas that can lead to real business transformation.

But we aren’t all lucky enough to get these types of opportunities and it’s often difficult to justify the cost of traveling to far-flung events in the modern business world. If you’re in that boat, then it’s your lucky day: our Layer 7 API Strategy Workshop series aims to bring all the experiences, discussions and networking opportunities practically to your doorstep.

Over the next two months, Mike Amundsen, Holger Reinhardt and I will be delivering a series of free workshops on API strategy, the principles of good API design and the keys to designing an API that will last. In addition to core aspects of effective API design, we will discuss the emerging trends of developer experience (DX), the Internet of Things (IoT) and DevOps as they pertain to the API universe.

Our tour kicked off in September with great events in San Antonio and Los Angeles and it will continue through October and November with the following stops:

It’s going to be an exhausting couple of months for us but we’re looking forward to having some great conversations with our attendees. So, come out and join us during what promises to be a very thought-provoking and engaging series of half-day events.

September 26th, 2013

Common OAuth Security Mistakes & Threat Mitigations

OAuth SecurityI just found out we had record attendance for Wednesday’s API Tech Talk. Clearly, there’s an appetite for the topic of OAuth risk mitigation.

With our digital lives scattered across so many services, there is great value in technology that lets us control how these service providers interact on our behalf. For providers, making sure this happens in a secure way is critical. Recent hacks associated with improperly-secured OAuth implementations show that OAuth-related security risks need be taken seriously.

When in doubt, take a second look at the security considerations of the spec. There is also useful information in RFC6819 – OAuth 2.0 Treat Model & Security Considerations.

The Obvious Stuff
Let’s get a few obvious things out of the way:

  1. Use SSL (HTTPS)
  2. Shared secrets are confidential (if you can’t hide it, it doesn’t count as a secret)
  3. Sanitize all inputs
  4. Limit session lifespan
  5. Limit scope associated with sessions

None of these are specific to OAuth. They apply to just about any scheme involving sessions and secrets. For example, form login and cookie-based sessions in Web applications.

OAuth’s Main Attack Vector
Some of the grant types defined by the OAuth protocol involve the end-user being redirected from an application to a service provider’s authorization server where the user is authenticated and expresses consent for the application to call the service provider’s API on its behalf. Once this is done, the user is redirected back to the client application at a callback address provided by the client application at the beginning of the handshake. In the implicit grant type, the redirection back to the application includes the resulting access token issued by the OAuth provider.

OAuth’s main attack vector involves a malicious application pretending to be a legitimate application. When such an attacker attaches its own address as the callback for the authorization server, the user is redirected back to the malicious application instead of the legitimate one. As a result, the malicious application is now in possession of the token that was intended for a legitimate application. This attacking application can now call the API on behalf of the user and wreak havoc.

OAuth 101: Callback Address Validation
The most obvious defense against this type of attack is for the service provider to require that legitimate client applications register their callback addresses. This registration step is essential as it forms the basis of a user being able to assess which application it is granting to act on its behalf. At runtime, the OAuth authorization server compares these registered values against the callback address provided at the beginning of the handshake (redirect_uri parameter). Under no circumstance should an OAuth authorization server ever redirect a user (along with an access token) to an unregistered callback address. The enforcement of these values is a fundamental precaution that should be engrained in any OAuth implementation. Any loophole exploiting a failure to implement such a validation is simply inexcusable.

redirect_uri.startsWith(registered_value) => Not good enough!
Some application developers append client-side state at the end of runtime redirection addresses. To accommodate this, an OAuth provider may be tempted to merely validate that a runtime redirection address starts with the registered value. This is not good enough. An attacker may exploit this by adding a suffix to a redirection address – for example, to point to another domain name. Strict redirection URI trumps anything else, always. See http://tools.ietf.org/html/rfc6819#section-5.2.3.5.

Dealing with Public (Not Confidential) Clients
If you are using the authorization code grant type instead of implicit, a phishing attack yields an authorization code, not the actual access token. Although this is technically more secure, the authorization code is information that could be combined with another vulnerability to be exploited – specifically, another vulnerability caused by improperly securing a shared secret needed to complete the code handshake in the first place.

The difference between the implicit and authorization code grant types is that one deals with public clients and the other deals with confidential ones. Some may be tempted to rely on authorization code rather than implicit in order to add security to their handshakes. If you expose APIs that are meant to be consumed by public clients (such as a mobile app or a JavaScript-based invocation), forcing the application developer to use a shared secret will only lead to these shared secrets being compromised because they cannot be effectively kept confidential on a public platform. It is better to be prepared to deal with public clients and provide handshake patterns that make them secure, rather than obfuscate secrets into public apps and cross your fingers they don’t end up being reverse-engineered.

Remembering Past Consent Increases Risk
Imagine a handshake where a user is redirected to an authorization server (e.g. implicit grant). Imagine this handshake happening for the second or third time. Because the user has an existing session with the service provider, with which the authorization server is associated (via a cookie), the authentication step is not required and is skipped. Some authorization server implementations also choose to “remember” the initial expression of consent and will not prompt the user to express consent again – all in the name of better user experience. The result is that the user is immediately redirected back to the client application without interaction. This typically happens quickly and the user is not even aware that a handshake has just happened.

An “invisible” handshake of this kind may lead to improved user experience in some situations but this also increases the effectiveness of a phishing attack. If the authorization server does not choose to implement this kind of handshake and instead prompts the user to express consent again, the user is now aware that a handshake is at play. Because the user does not expect this action, this “pause” provides an opportunity for the user to question the action which led to this prompt in the first place and helps the user in recognizing that something “phishy” is in progress.

Although bypassing the authentication step provides an improvement in user experience, bypassing consent and allowing redirection handshakes without displaying anything that allows a user to abort the handshake is dangerous and the resulting UX gain is minimal (just skipping an “OK” button).

September 19th, 2013

Did Apple Just Kill the Password?

Written by
 

Password KillerOn the surface, Apple’s recent iPhone 5S announcement seemed just that: all surface, no substance. But as many reviewers have pointed out, the true star of the new model may not be its shimmering gold sheen but instead the finger sensor built into its home button.

Using a fingerprint to prove you are who you claim to be is not new. But building it into a phone is. And as your mobile phone becomes your carrier of content (like photos), currency (like digital wallet) and identity (like keychain) as well as your route to all manner of digital services, proving who you are will become essential for mobile everything.

Before mobile, Web security rooted itself in the username/password paradigm. Your username and password defined the identity you used to authenticate yourself to PayPal, Amazon, Google, Facebook and everything in between. There are stronger ways to secure access to Web sites but written passwords predominate because they are personal and easy to type on a PC, where all Web pursuits took place – until the arrival of the smartphone, that is.

The smartphone and its similarly keyboard-deprived cousin, the tablet, increasingly represent the jumping off point for the Internet. Sometimes, it may start with a browser. Many times it begins with an app. In either case, passwords are no fun when you move to a mobile device. They are cumbersome to type and annoying when you have to type them repeatedly across multiple sites, services and apps. So, anything that diminishes the burden of typing passwords on a mobile device is a good thing.

Apple is not alone in identifying that end users want ways to eliminate passwords on mobile. Our company, CA Technologies, has a sizeable franchise in Single Sign-On (SSO) and strong authentication technologies, which – when applied to mobile – can significantly reduce the burden of recalling multiple passwords across different sites, apps and services. In fact, CA Layer 7 hosted a webinar on this very topic this morning. But what Apple has achieved is significant because it substitutes a highly-personalized biometric for a password. This has the power to streamline mobile commerce, mobile payments and every other kind of mobile-centered interaction or transaction.

Many commentators have rightfully pointed out that biometrics do not offer a panacea. If your fingerprint gets hacked, for instance, it’s hacked permanently. But there are easy ways of augmenting biometrics to make them stronger. Biometrics can be combined with over-the-air tokens like one-time password or supplemented with context-aware server-side challenges that increase their requirements based on risk. But it’s what they achieve when compared with the alternative that makes fingerprint readers so powerful.

The 5S simplifies authentication for the average user, which encourages security use and acceptance. It also eliminates bad mobile habits like using short, easily memorable, easy-to-type passwords that scream insecurity. Apple is not the first vendor to realize consumers don’t like passwords on mobile devices. But by bringing an alternative to the mass market, it is helping to draw attention to the need and the opportunity: killing the password may open mobile to a whole host of novel security-dependent Internet services.

September 17th, 2013

Mobile SSO: Give App Users a Break from Typing Passwords

Written by
 

Mobile SSOJust a reminder – on Thursday, I’ll be presenting a webinar alongside Tyson Whitten, Director of Solutions Marketing at CA Technologies. We will be talking about CA/Layer 7’s new Mobile Access Gateway 2.0 release and how it addresses two important questions associated with enterprise-level mobile app development, including business-to-consumer apps and internal/BYOD apps:

  • How do you establish security for mobile apps that consume backend APIs?
  • How can you create a Single Sign-On (SSO) session for multiple apps?

Tyson and I will also be discussing how you can use the Mobile Access Gateway to manage the relationships between users, apps and devices by leveraging standards like OpenID Connect, OAuth and PKI. The Gateway makes it possible to maintain mappings between the different token artifacts so that IT security can set fine-grained access policies for securing the backend APIs the apps use.

Mobile Relationships

If you have already deployed CA SiteMinder or a mobile device management (MDM) solution, you should consider deploying the Mobile Access Gateway to get your infrastructure ready for the app revolution.

If you haven’t already signed up to webinar, you can do it here:

September 13th, 2013

Nordic APIs

Nordic APIsIt looks like the remainder of September will provide a bounty of learning opportunities for those of you interested in diving deeper into API design.  To start with, Mike Amundsen and I will be continuing our Layer 7 API Academy workshop tour in Montreal and Calgary. In addition to our API Academy events, Mike will be hosting his annual conference related to all things REST with RESTFest 2013. I had the pleasure of attending last year and I highly recommend going if you are interested in thought-provoking conversation and ideas in the hypermedia domain.

On the other side of the ocean and closer to home for me is next week’s Nordic APIs conference in Stockholm (September 18-19).  I’ve been to a few of the smaller API design conferences that the Nordic APIs team has put on and I can say without a doubt that this will be a conference worth attending.  They’ve always done a great job of putting together sessions that will appeal to developers on the leading edge of API design as well as those who are looking for practical solutions.

I’ll be delivering a keynote presentation on a developer experience (DX) oriented design approach for APIs. My colleague Holger Reinhardt will be talking about the Internet of Things and Aran White will be delivering a demonstration of the Layer 7 product line. Of course, the great value in events like this comes from the serendipitous conversations that take place outside the agenda and Holger, Aran and I are really looking forward to swapping war stories with Nordic API attendees.

While I’m sad that I won’t be able to join Mike at RESTFest this year, I’m overjoyed at the reason I can’t go. I’m continually amazed at how much the European API design community has grown and watching the Nordic event grow from a few small events into a major conference has been eye opening. Not too long ago, it was difficult to find API design events to attend but now we are spoiled for choice. It’s a great indication of the continued interest in and growth of Web-based APIs.