KeepItLocked.net

For my User Interface Design class last semester, my team created a CAPTCHA mechanism with an interface suited to mobile devices. I recently made a Mobile CAPTCHA project page describing the project. There's also an interactive prototype at bit.ly/mobilecaptcha and a Video Prototype on YouTube.

Recently, UC Berkeley has announced that they will offer complimentary DNA testing to incoming Letters and Science freshman. The testing will be optional, confidential, and look at three genetic markers related to alcohol, lactose, and folate tolerance. While the project intends to provide a unifying educational experience and help students prevent health issues, it has become the subject of criticism because of the ethical and privacy concerns associated with genetic information.

One dimension of the system that should not be ignored is the threat model. According to the FAQ on privacy for the program, the confidentiality of the system relies on two bar codes sent to each student. The student sends one back and keeps the other to view the results. This description is too simplistic to give me any confidence in the system. In order to provide confidentiality, these barcodes would need to be randomly generated. There would never be a time when the bar codes associated with student names were viewable by another person (who is stuffing the envelopes?). And, the web site that provides the information would have to be free of security vulnerabilities. Given that the only time I'm ever received an SB1386 "sorry, we've been hacked" letter was from UC Berkeley and involved a website compromise, I think that this is a big assumption.

Like other dilemmas involving ethics and privacy, the people responsible for the decision should deeply consider the security risks. Ensuring privacy often means ensuring the confidentiality of information, which is tremendously difficult to guarantee. I'd like to see more organizations analyze and present the security concerns and how they impact privacy before making unfounded guarantees and rushing towards their desired conclusion.

I recently attended the Internet Identity Workshop 10 (IIWX) at the Computer History Museum in Mountain View to learn about the direction of OpenID. I spent many hours this semester researching and writing a paper for school about social factors limiting the diffusion of OpenID. Between the time that I came up with the idea for the paper and I turned it in, the OpenID and surrounding community has become involved a series of fascinating conversations that seem, to me, to be the future of the Internet playing out in a day-to-day drama.

OpenID has had only limited success. There are many reasons - security, usability, trust issues, and legal issues are some of the obvious ones. There are also competitive standards. Sites like Twitter and LinkedIn allow you to authenticate via OAuth. But wait, I though OAuth was for authorization, not authentication? OpenID and OAuth both support authentication and authorization in some form. And the two standards seemed to be in a steel cage match. Enter Facebook.

Facebook had a platform for single-sign on and sharing across the web called Facebook Connect. It was, for the most part, a closed and proprietary standard that didn't acknowledge the existence of OpenID and OAuth and the other elements of the OpenStack. In 2009, Facebook joined the OpenID Foundation and became an OpenID Relying Party (RP) by accepting OpenID accounts. This was in contrast to other large companies like Microsoft, Google, and Yahoo, who are only OpenID Providers (OP) and don't allow you to log in to their services with another identity. Essentially, Facebook said, "fine, you can log in to Facebook with your OpenID. But we want to make sure you log in to other sites with Facebook Connect, not OpenID." Facebook has taken a lot of flak for privacy debacles - from Beacon to their dynamic privacy policies. Some suggested that Facebook Connect was an attempt to make Facebook the identity layer for the web. Since you are always logged into Facebook (right?), sites could access your social graph (not to mention verify your geographic location and age) through the information shared from your profile via Facebook Connect.

Facebook recently revealed that they were killing the proprietary Facebook Connect stack and replacing it with OAuth 2.0. OAuth 2.0 is a re-imagining of the OAuth protocol that promises to make life simple by eliminating the need to perform cryptography on the client with Bearer Tokens and requiring SSL to improve security.

So now, if you want to allow users to log in to your site with their Facebook or Twitter accounts, you had to support OAuth, not OpenID. And guess what, site owners? There's good news. The OAuth protocol gives you a token that lets you get all sorts of fun data about users. So why would you even need OpenID?

At the recent Facebook f8 conference, several influential members of the Identity community hosted a panel discussing the OAuth 2.0 changes. When asked about OpenID, a Facebook engineer replied: "Developers aren't asking for OpenID. OpenID [is] a layer of complexity nobody is asking for." This was followed by an informal poll showing an overall lack of enthusiasm for the OpenID technology.

So wait, OpenID is done for? That's what I wanted to figure out at this conference. A few days earlier, David Recordon dropped the Open ID Connect strawman proposal, which was discussed further at several IIW sessions. Generally, OpenID Connect builds on top of OAuth 2.0 and includes plenty of inspiration from earlier OpenID/OAuth hybrids. The idea is to move the OpenID itself to a single "scope" of an OAuth flow. The move to OAuth 2.0 forces everyone to use SSL, which happens to break OpenID 2.0.

Even if it breaks backwards compatibility, I think OpenID Connect would encourage OpenID adoption. It simplifies OpenID, which is a critical hurdle, and provides default security in the form of SSL. It also gives sites the carrot of an OAuth token and potentially rich social information about its users. This is what concerns me about tightly integrating OpenID and OAuth. I think it will encourage services to only accept third-party logins from sites that have lots of social information about users, as opposed to allowing arbitrary OpenID URLs.

If Facebook, Google, and Twitter are on board, full steam ahead, right? But OpenID Connect is just a strawman proposal. There's an entirely different OpenID charter called v.Next. The two proposals share a lot of the same goals, and seem to involve a lot of the same people. But, in the meetings at IIW, you could sense a tension between the two sides. OpenID Connect is about, at its core, simplicity. The decision to build OpenID Connect on top of OAuth 2.0 is a fait accompli. v.Next wants to support Public Key Infrastructure, it wants to provide NIST Levels of Assurance, it wants to support existing OpenID infrastructure like Attribute Exchange. OAuth 2.0 compatibility is a nice to have. The two sides seem to have fundamentally different visions for the technology. From the OpenID Connect proposal:

Q: Haven't there been OpenID Foundation Working Group proposals for OpenID v.Next?

A: Yes, there have been proposals for working groups on discovery and attributes over the past month (and talk about doing so for almost a year). Combined they have over a dozen new features and there hasn't even been a proposal for the core OpenID Authentication spec yet. OpenID needs to be driven by simplicity and elegance, not by support for over a dozen new features.

So who will win out? My hope is that the next OpenID standard will be a compromise between the two parties. There are several tradeoffs here: simplicity versus extensibility, privacy versus usability, security versus complexity, and so on. I'm worried that the v.Next vision to support everyone doing everything sounds a lot like the WS-* debacle, where there seem to be more specs than there are implementations. On the other hand social behemoths Google, Twtter, and Facebook are prominently involved in the OpenID Connect specification that encourages social sharing and may (just may) disempower users who find themselves forced to share potentially embarrassing information in order to register for sites. Hopefully a fine line can be drawn to protect users interest and support a wide set of use cases, while keeping OpenID simple enough to encourage people to use it.

Irony footnote: Yes, I don't have OpenID enabled for comments on the blog. Yet.

This blog hasn't been getting the love it deserves. My last post is almost a year old! What gives? Well, as I mentioned, I went back to school. I finished up my first year last week, and it was amazing(ly time-consuming). I'm hoping to distill some of what I've been working on in a series of blog posts in the next few weeks. I'd also like to make a renewed effort to update this blog and keep it current with content this summer, next year, and beyond. Stay tuned!

The second version of the .NET port of the ESAPI project is available for general review. The code is available on Google Code here.

The ESAPI (Enterprise Security API) is a set of OWASP projects that support secure software in a variety of languages. I’ve worked closely with the ESAPI team to create a .NET version. While there has been .NET ESAPI code available for quite some time, this release should be much more applicable to real-world projects, especially ASP.NET development. This blog post is meant to cover some of the highlights in an FAQ format.

What is the general design of the .NET ESAPI?

If you’ve looked at the Java ESAPI before, you won’t be surprised about the structure and design of the .NET version. The .NET ESAPI is split into three projects: Esapi, EsapiTest, and SwingSet.

The first project is named Esapi, and contains the interfaces and the reference implementation. This is all you need if you are developing a .NET application from scratch. You would simply add the assembly from this project as a reference (along with the other required references), update your configuration file to add the appropriate ESAPI configuration elements, and extend the reference classes as you see fit.

This project contains four sub-namespaces.The Codecs and ValidationRules namespaces are used for the reference implementation of the Encoder and the Validator components, respectively. The Errors namespace contains the Exceptions used in the reference implementation. The Interfaces namespace contains the interfaces, which are implemented in the reference implementation, which is in the base namespace.

The EsapiTest project is a Visual Studio test project which contains several test cases for the reference implementation. If you have a patch, you could create a test case for whatever functionality you are updating and include it in the patch. There are over fifty unit tests currently in the project.

The SwingSet project is an ASP.NET application that has a few different purposes. One purpose is to demonstrate how to integrate the ESAPI components into an ASP.NET application. However, it also demonstrates security best practices outside of the scope of the the ESAPI. For example, it contains an example of how Membership can be configured securely. Additionally, the web.config file is annotated with security descriptions for some settings.

What different ESAPI components are supported?

The following components are supported:

• IAccessController: The IAccessController interface defines a set of methods that can be used in a wide variety of applications to enforce access control. In most applications, access control must be performed in multiple different locations across the various application layers. The interface is built around the idea of subjects, actions, and resources. A specific subject/action/resource combination is known as a rule.
• IAccessReferenceMap:The IAccessReferenceMap interface is used to map from a set of internal direct object references to a set of indirect references that are safe to disclose publicly. This can be used to help protect database keys, filenames, and other types of direct object references.
• IEncoder: The IEncoder interface contains a number of methods related to encoding input so that it will be safe for a variety of interpreters.
• IEncryptor:The IEncryptor interface provides a set of methods for performing common encryption, random number, and hashing operations.
• IHttpUtilities:The IHTTPUtilities interface is a collection of methods that provide additional security related to HTTP requests, responses, sessions, cookies, headers, and logging. This class handles CSRF protection.
• IIntrusionDetector: The IIntrusionDetector interface is intended to track security relevant events and identify attack behavior.
• ILogger: The ILogger interface defines a set of methods that can be used to log events.
• IRandomizer: The IRandomizer interface defines a set of methods for creating cryptographically random numbers and strings.
• ISecurityConfiguration: The ISecurityConfiguration interface stores all configuration information that directs the behavior of the ESAPI implementation.
• IValidator: The Validator interface defines a set of methods for validating untrusted input.

How is the .NET ESAPI different from the Java ESAPI?

The two projects are very similar in spirit, but there are some key differences. Most of the differences exist because the .NET ESAPI is a less complex project, although in some cases they exist because I disagree with the direction of the Java team.

• There is no User component in the .NET ESAPI. While this is a big piece of the Java functionality, it significantly overlaps with the existing .NET Membership API. I’ve decided to use the Membership API in the reference classes, rather than re-invent the wheel of user management.
• The Encoder class uses the AntiXss library. Again, there was significant overlap, and I felt there was no need to duplicate functionality. However, this means that canonicalization is not fully supported yet, since AntiXss only does encoding, not decoding.
• HttpUtilities is extremely simple, with only a few supported methods. There are no wholesale request validation or logging methods, and interactions with the request itself are not protected.
• The Logger implementation is very simple. It points to the Log4Net logger, which is configured independently of the ESAPI. There is no requirement to use Log4Net – you can write your own ILogger implementation that uses a different library.
• IAccessReferenceMap has a somewhat different and, in my opinion, more consistent interface.
• IAccessController is significantly simpler. It is based on the subject, action, resource access control paradigm (who does what to whom) and makes no assumption about how you will store these rules in your project.
• SwingSet is both a reference and a starter kit. It contains examples of how to use the ESAPI in addition to other secure ASP.NET best practices.

How do I use the .NET ESAPI?

There are a couple of ways to get started with the .NET ESAPI.

If you simply want to start using the functionality, you can download the assembly and supporting files here. You will need to add Owasp.Esapi.dll and log4net.dll as references, and add the App.config settings to your configuration file. The documentation is available for download as a .chm file here or online here.

I would recommend downloading and exploring the entire solution so that you can become comfortable with the code. You can download the solution from Google Code with SVN. The solution is created with VS 2008 and .NET 3.5 (the actual code should be compatible with .NET 2.0, so it should be pretty simple to get it to compile in most environments). You can then run the unit test project and the SwingSet project to see how the .NET ESAPI works.

You will need to download and install the AntiXss library separately, in order to respect the code licensing.

The SwingSet application requires you to login – first you need to register a username. To do this, you also need to supply a SMTP host in the web.config file in SwingSet so that you can get an activation email. You can just use the external SMTP server for an email account you own and use that - i.e.
    <mailSettings>
      <smtp from="dot-net-esapi@owasp.com">
        <network
             host="you fill this part in, for example d.mx.mail.yahoo.com for a yahoo.com mail account"
             port="25"
             />
      </smtp>
    </mailSettings>

Is the .NET ESAPI mature/stable?

It’s getting there. At this point, it’s still a little early to call the .NET ESAPI a beta project – I hope that this release will allow enough people to provide feedback and join the team that we can get there soon.

How can I contribute?

First and foremost, join the ESAPI list. Feel free to contact me (me AT alexsmolen DOT com) and let me know if your interested in helping out – my first reply will be to download, use, and provide feedback on the current project. So far, I’ve had some real help from people like Paul Apostolescu and Taco Ditiecher. Thanks!