Recently in Security Category

Tons of passwords are an unfortunate reality. I'm working hard every day to reduce the number of passwords that we have to use around the Web. Till it gets to a management number though, we need a way to cope. Everyone has a technique -- some put their passwords in a spreadsheet, others write them on post-its stuck to their computer screen, others use the same password(s) everywhere, some use a password manager in their browser. All of tese techniques have various security implications, however. We have to manage this chaos some how though, so the security issues are often disregarded. Is there a more secure way?

A better alternative would be one that doesn't require you to write anything down, isn't locked away in a computer that you don't have ready access to, and is unique per site and per account. One such technique is to create a set of steps, an algorithm, that you follow to create a unique password for every user account on every site that requires one. To do this, start by using something from the Web site that won't change, like the name; this is your "seed" value. For instance, your algorithm could be something like this:

  1. Capitalize the first letter of the Web site's name and make the rest lowercase.
  2. Take the first 4 characters of this name. If it is less than four characters, add underscores to make it at least four characters long.
  3. Add some word that contains a symbol and a number and is easy to remember (e.g., [email protected]). The result is the password to use on the site.

So, using this sample algorithm, the password for CNN would be this:

  1. Cnn
  2. Cnn_
  3. [email protected]

For Spotify, it would be this:

  1. Spot
  2. Spot
  3. [email protected]

The result is a strong passwords that while difficult to remember is easy to reproduce because the necessary steps are memorable. There's a problem w/ this though. If a baddie ever sees just two of your passwords, they'll have a very easy time guessing any of your others because they are so similar. So, here's an easy fix that makes things more secure

Download an app to your phone that can generate a password from an input phrase. This app should produce the same password every time it's given the same input. It should produce passwords that includes uppercase, lowercase, numbers, and symbols. This app should not have permission to access the Internet. Some of the free ones require it, so they can download ads. Who knows though? They might also be uploading your passwords. An example of a good one for Android is Password Generator Pro.

Now, when you have to sign up for a new account and create a password, use your algorithm as described above. However, don't use that as the password. Instead, use it as input to the app. This will produce a random password from a phrase that's hard to guess but associated to the site you're visiting. With the the site-specific "seed," the common algorithm, and an app that's running on your phone which generates strong passwords, you'll have a pretty easy system for managing the chaos where you don't have to write anything down, each password is unique, and they can't be guessed.

Make sure you don't let people know your algorithm though or all this security breaks down.

If you have a better way to manage this mess or if you think there are issues w/ this system, leave a comment here or drop me a line.

Last Monday, AT&T announced that they have launched a new API platform. As I wrote about on Kin Lane's API Evangelist blog, the PaaS includes various components to help developers quickly build and launch new applications. One of these is an HTML5 SDK that simplifies what mobile Web application developers have to do to securely call the mobile network operator's new cloud services.

The carrier is securing their API with OAuth 2. They support both the authorization code and client credentials grant types defined by that spec. att-oauth2.gifThey also allow users to authenticate to the Authorization Server (AS) w/ a username/password, a MSISDN and a PIN, or by simply being connected to their network. Also, each of the services has a different scope. To get approval to use them, the app developer includes these when redirecting the subscriber to AT&T's AS.

The various authentication mechanisms are interesting, but what's even more intriguing to me is a Sencha Touch plug-in that is included w/ the SDK and how it works in tandem w/ a proxy. The plug-in exposes a JavaScript object model for the new cloud services that works naturally w/ this popular toolkit. Extending Sencha Touch like this allows developers who are already using that framework to quickly integrate the carrier's new services. For others that are not, it allows them to build UIs that look and feel like native apps on various mobile platforms while simultaneously simplifying the use of AT&T's API. To see how, let me explain how the Sencha Service Access Layer (SAL) works w/ the proxy.

att-paas-arch.pngAs shown in the following figure, all requests to the AT&T cloud go through an intermediary. This proxy is hosted by the same developer as the HTML5 app. The first time a user invokes the application, it will call the proxy which will find that it doesn't have an OAuth Access Token (AT) or Refresh Token (RT). For this reason, it will return an error rather than calling the carrier's cloud service. The Sencha plug-in will catch this and pop up an IFRAME displaying AT&T's OAuth AS. (The samples don't display the address, but I would.) The user will authenticate as described above, and the AS will redirect the IFRAME to the callback handler which is hosted on the same server as the proxy. It will exchange the Access Code (AC) provided on the query string for an AT and RT. These will be persisted in a session. Subsequently, when methods are called on the plug-in, a request will be made to the proxy, the session will be used to find the AT, and the proxy will tack it onto the request that it forwards to AT&T.

This new API and its SDK provide an innovative way of using OAuth that simplifies the work that mobile Web application must do. The docs were great, the samples were very helpful, and I quickly figured out how to use the toolkit. I also found it interesting that a helper was used here to aid in securely consuming services from mobile apps as I've talked about doing for other use cases.

If you have questions or thoughts about this or the other blog post I wrote about this new API, please feel free to lave a comment here or drop me a note.
I got an email the other day from Pedro Félix, asking for my thoughts on an OAuth scenario that he was wondering about and discussing with Howard Dierking. As Pedro and I talked, I learned that he had a really interesting problem on his hands. Basically, he wanted to create an OAuth 2.0 protected service that called an OAuth 1.0a protected service (e.g., Twitter). So, what he had on his hands was a bunch of clients, tokens, services, and two different protocols that do things similarly but w/ slightly different names. Very confusing stuff.

To begin making sense of all this, it's helpful to list out what we know:

  • Pedro wants to call the Twitter API from his own API.
  • The Twitter service is an OAuth 1.0a Resource Server (RS).
  • Twitter has an OAuth 1.0a Authorization Server (AS).
  • The Twitter service naturally only trusts it's own AS.
  • Pedro's service is an OAuth 2 RS and an OAuth 1.0a Twitter client.
  • Pedro has an OAuth 2 AS.
  • Pedro's service naturally only trusts his own AS.
  • The Web app that calls Pedro's service is an OAuth 2.0 client and must submit Access Tokens (ATs) emitted by his own AS (not Twitter's) when calling his service.
  • The Resource Owner (RO) is a Twitter user and will authorize Pedro's service to call the Twitter API to modify their data.
  • The RO authenticates to Pedro's AS using Twitter's OAuth 1.0a AS.
  • Pedro's AS asks the RO to authorize the third-party client to access his service which in turn will access Twitter's.

With these basics in mind, have a look the the following picture that presents an overview of the actors involved:

oauth-to-oauth2.gif


Now, to get an idea of how Pedro's service would call Twitter's, flip through animations in the following slide deck.

See how one OAuth protected resource can call another? Pretty cool stuff! It's also cool that if instead Pedro wanted to call the Facebook graph API which uses OAuth 2, it would work almost the exact same way. As if that we're cool enough though, what's even cooler is that this isn't just theory. I was able to implement this in PingFederate in about half the time it took me to write this blog post! If I have some time over the weekend when I'm not celebrating my little one's second birthday, I'll try to post a screencast.

Anyway, thanks Pedro and Howard for inviting me into your conversation. If you or anyone else has questions about this or other OAuth matters, please feel free to post a comment here or send me a mail.
The other day I wrote about a way to use OAuth w/ mobile apps that was not susceptible to phishing and does not use the password anti-pattern. I just had to code it up and make sure it worked. What better time then 4 AM when the house is quite? Ah, jet leg ;-)

Using Lars Vogel's tutorial on C2DM, PingFederate's new OAuth server, and a little Python Web app running on CherryPy, I found that it does actually work! Here's the high-level points to be aware of if you want to implement this:

  • The C2DM API is in beta, and you'll need to sign up for access using a Google account. Developer accounts have a limited quota.
  • You need to provide the email address you sign up w/ and a password to the Google ClientLogin service to get an OAuth-like Access Token (AT). You don't have to use your own password though; you can create one specifically for this purpose (which you'll have to do if you're using 2FA w/ your account like I am).
  • These tokens need to be renewed every so often, so, in your Web app, keep an eye out for errors. (It's not indicated by the HTTP status code but the contents of the body IIRC.)
  • PingFederate's OAuth token endpoint is configured w/ a self-signed SSL cert by default, so you'll need to work around that during development.
  • There can be a bit of leg between the time you publish the OAuth Access Code (AC) and the time your app gets the message. Meanwhile, your user will be looking at a blank white browser window. To avoid this second or so delay, you can register a customer scheme in your app. Then, in the helper Web app, return a 302 to that as soon as you send the AC to the Google C2DM service. This will cause the app to come to the foreground immediately. Alternatively, put a little spinner in the Web page.
That's basically it. If you follow Lars' tutorial and keep these things in mind, I'm sure you'll be up and running in no time -- especially if you've woken up before anyone else and it's really quite out ;-) Here's a little demo of it running that will hopefully motivate you to get it coded up too. If you get stuck, drop me a note.

When creating a native mobile app, it is often necessary to call RESTful Web services securely using OAuth. To do this, the native app needs an Access Token (AT). There are various ways for the app to get such a token, each presenting certain pros and cons. Around the Web, you will find two primary suggestions on how to do this:

  1. From the native app, pop open a browser to the Authorization Server (AS) where the user will authenticate and authorize the native app to access their resources. Return the AT to the native app via a scheme registered with the mobile OS.
  2. Embed a Web browser control in the native app that renders the AS's Web pages inside it and get the AT as it goes by.
The problem with the first is that multiple applications can register for the same scheme, opening up the native app to phishing. The latter is a problem because the native app can see everything that goes by including the Resource Owner's (RO's) credentials. This is OK if you trust the app not to do that, but that isn't always the case and is reminiscent of the password anti-pattern that OAuth was designed to fix. For more details on these attacks, see this whitepaper (PDF).

At IIW this week, Personal's CTO, Tarik Kurspahic, organized a session to talk about how best to get OAuth tokens into native apps. In it, he, Scotty Logan of Stanford University, myself, and the other participants came up with the following alternative to the popular suggestions above which does not allow the installed app to see the RO's credentials and is not susceptible to phishing.

Here's a diagram showing what we came up w/.

oauth_mobile.gif

This is basically traditional 3-legged OAuth w/ a twist, but it's involved. So let me explain:

  1. The native app pops open the mobile phone's browser to a Web page that is developed and hosted by the same org that owns the native app. On the URL of this request is the registration ID of the app. This ID is unique to the app on a particular device and is provided by the Google or Apple notification service (see below).
  2. This Web page redirects the RO's Web browser to the AS. In the 302, it stores the registration ID in a cookie.
  3. The RO authenticates to the AS and grants the native app access their resources.
  4. The AS redirects the RO back to the helper page which is registered as the callback. On the query string of this request in the Access Code (AC) and the cookie w/ the registration ID is also sent.
  5. Rather than resolving this code for an AT as in a traditional Web server flow, it sends the AC as the payload to either Google's or Apple's notification service. To do this, the helper app needs to use an app-specific credential to authenticate to the notification service. By authenticating the call w/ this app-specific key and by providing the saved registration ID, only the right app on the right device will receive the AC.
  6. The notification service sends the message to the appropriate app on the appropriate mobile device.
  7. The app then sends the AC to the AS to get an AT.
  8. It can then use the AT to securely call the API.

After the session, I ran this by Paul Madsen, Brian Campbell, and others. No one found any issues w/ it, but, like some in the session, they wondered why such a complicated arrangement was needed. Till the folks on the Android team and at Apple provide secure IPC in their mobile OSes, I don't see any alternative unless you can make certain assumptions or are comfortable w/ the risks associated w/ the common alternatives. If you know a better way or see any security issues w/ this, please leave a comment below or drop me a line.

Thanks all for a great IIW and see ya in the spring!