There’s a great discussion taking place on the OAuth list around how to make it easier to deploy. It was started with a post by Kent Brewster lamenting the problems he ran into. His post is a fun read, I’ve only snipped the top-level bullets:
- My Timestamp was Stale
- The Parameters in my Signature Base String were Out of Alphabetical Order
- I Forgot a Question-Mark between my Request and my OAuth Payload
- I Didn’t URL-Encode my Signature
- I Didn’t URL-Encode All Illegal Characters
- I URL-Encoded the Ampersands Separating my Method, URL, and Request Parameters
- I Didn’t Append an Ampersand to my Consumer Secret to Make my Signature Key
- I Used the Same Nonce, Over and Over and Over Again
- I Generated a Random Nonce, but (you guessed it) Failed to URL-Encode It
- And, Finally: I URL-Encoded my Signature Key
That post sparked a note by Chris Messina asking others if their experience is similar. What follows, then, is a useful thread on what might help make it easier for others.
The reason I find this interesting? Because, IMO, focus on this type of work is what will help move the ball forward. Whether it’s OAuth, OpenID, SAML, InfoCards, or whatever, these are solutions that interface with real people doing real code. The easier the deployment, the fewer mistakes and more time to focus on security over sytax, etc.
…and happier coders. 
April 28th, 2009 | 
User-Managed Identity Starts at Home
About 8 years ago I took on the challenge of securing the digital borders around the e-commerce systems for the Kraft Group’s sports properties. At that time, I could see a storm cloud gathering on the networked horizon as we built a system to unify all of the current properties and set the foundation to build out a series of interconnected portal communities. Looking forward, I knew that it was only a matter of time before a major press-worthy event would raise everyone’s awareness regarding the protection of user privacy, in the form of personally identifiable information (PII), and associated payment information.
Our business strategy was to build a core commerce engine that could handle online transactions embedded within each separate portal. Key to our success was enabling users to have a persistent identity throughout their engagement with our products. In this way we could minimize the barriers to their interacting with our content, as well as streamlining the purchase pipeline. Essentially, once users logged into any of our portals (to access premium/personalized content, manage accounts, and purchase products), we were able to effectively cater to them by simplifying their experience.
The problem with this single-sign-on model was that if a user account was compromised, the intruder could have free reign over the victim’s PII and associated payment information. I had to make the case for going the extra mile(s) by designing strict access control procedures, knowing that something bad was going to happen to a company soon and that we should be ahead of any reactionary solutions imposed upon us. I had a feeling that after some bad press, the e-commerce industry would be pressured to lock down the porous borders that were relatively common at the time.
Just such a case occurred in 2004 when hackers were able to access an estimated 8 million credit card numbers from BJ’s Wholesale Club. It took a few years for details of the incident to emerge, but it was clear even then that there were two primary issues: insecure access points, and poor audit logging. Regardless of whether it was an inside job (as was initially assumed) or an outside hack (which it turned out to be), BJ’s (among other compromised companies) had poor access control and monitoring.
This, as well as other similar incidents, prompted the creation of the Payment Card Industry Security Standards Council, founded in 2006 by American Express, Discover, JCB, MasterCard, and Visa. The payment card industry thus began requiring strict practices and controls around systems that perform above a modest threshold of transactions. It was a strong move, in advance of looming legislation, that helped steer wayward companies toward better practices. Regardless of the critiques of their programs, it has succeeded in shining a light on many problems needing to be addressed.
Fortunately, by the time the PCI guidelines hit the market, we were able to breeze through their audits. The commerce engine we’d built was tighter than what they required. It’s rare that you can so easily point to a situation like this where the extra capital cost on the front end so clearly saved money that would’ve been required to retrofit a running system.
Now, here’s where the history lesson circles around to become informative for current events. We should learn from these cases of identity intrusion and address the core issues. The obvious lesson is not to be cavalier regarding the protection of your email accounts. After all, they are your core identity asset in today’s online world. Be careful when setting up your email account and follow common sense when selecting passwords and associated “remind me” features.
Beyond what you can do for yourself today, the industry needs to step up it’s game, too. Fortunately, there are a number of efforts currently under way to help protect your identity. They just need to be more whole-heartedly embraced and helped to mature by the major players in the market. What’s uniquely interesting about many of the emerging solutions is that they’re user-centric, rather than being centered around any one company’s digital security practices. This focus helps solve the root problems: privacy protection starts at home, and it’s not a simple matter of more/better cyber-security and encryption.
For more information, and to become involved, I highly recommend following the open standards development relating to user-managed identity:
And, of course, the Internet Society Trust & Identity Initiative. Tell them I sent you.