(Part of a series on Sun’s OpenID@Work initiative.)
When we put our OpenID provider through the security review wringer (many thanks to Glenn Brunette and his team for their work on this!), some nitsy OpenID protocol questions came out, along with issues of provider and consumer behavior in the wild. Some of these items were already well-known, but others haven’t gotten much of an airing before. I’ve cataloged the more interesting ones here.
Secret Key Lifetime
Request: Ensure that the lifetime of the association handle has some limit that is enforced by both the consumer and provider sides.
Action: None.
Commentary: The OpenID provider decides whether to offer an association handle, and can enforce how long an association is valid by simply answering a consumer request bearing an old handle with a response message that uses a new handle. In the OpenID Extension to OpenSSO that we deployed, this can be configured. In fact, in our deployment, the lifetime — in the case of a response message that invalidates the old handle — is limited to the very response message in which it appears.
For its part, the consumer is always free to throw away its association handle and go get a new one; the handle is there to save consumer time and effort in validating signed messages. The consumer also has the option of using dumb mode and asking the provider to verify the signature on the response message after receipt.
Finally, there is concern about using Diffie-Hellman to secure the negotiation of shared secret and association handle, as it is known to be vulnerable to man-in-the-middle attacks. The alternative, which Sun uses, is to require the key and association handle to be negotiated via SSL, avoiding the Diffie-Hellman mechanism entirely. If you use SSL and all parties actually verify the certs, you mitigate the MITM attack. (Our service offers a server certificate that can be verified by consumers.)
Inappropriate Identifier Strings
Request: The processes of registering for and wielding an OpenID should involve a check for unacceptable input in the identifier string. Allowing very long identifiers and identifiers containing special encoding characters introduces risk of buffer overflow and injection attacks. In addition, allowing sequences such as “../..” could expose other parts of the provider system to view (a directory traversal attack).
Action: Agreed to develop a list of unacceptable sequences.
Commentary: This is a well-understood issue in the “writing secure web apps 101” mold, but I haven’t seen it discussed as a concern in the OpenID community.
Inappropriate characters used during registration of an OpenID can present more than a security risk; because ultimately what’s being constructed is a URI, you have to follow the rules of URI syntax. It can be a usability nightmare to allow users to type in characters that must later be escaped in actual usage (such as %20 for spaces). The registration module in OpenSSO allows us to set the list of acceptable characters, which would mitigate both the security issue and the usability issue.
The Sun provider, it turns out, isn’t at risk of inappropriate directory traversal anyway because it’s deployed on the Sun Java System Web Server, which, like the GlassFish app server, takes the approach of requiring an explicitly written policy if you want access a resource outside the current app’s scope. (Some other app servers, however, may be at risk of this.)
The directory traversal issue is one of a host of well-known issues to look out for in building secure web apps. Another is cross-site request forgery (CSRF/XSRF, already highlighted in Stefan Brands’ now-famous catalog of OpenID issues), which many providers seem susceptible to. Another issue we noticed during testing with OpenID consumer sites is that many of them don’t check their own nonces to prevent replay attacks.
Paul Bryan, the developer of the Extension to OpenSSO that we deployed as our OpenID provider, tells me that he had an explicit goal to harden the OpenID functionality because he anticipated that it might, someday, become part of OpenSSO proper. This led him — and Hubert, who developed our deployment — to take measures that seem to go beyond the provider security features commonly found in the wild.
Monitoring of log files
Request: Implement monitoring of log files for evidence of brute force attacks on passwords, password reset attempts, entering invalid input into registration fields, etc. The monitoring should also check for someone trying to fill up log files or disk space.
Action: We agreed that we need to enable this functionality (some of which already exists in OpenSSO, some of which is provided by lower levels of the stack, and some more sophisticated parts of which might need to be custom-developed).
Commentary: This item has nothing to do with OpenID or OpenSSO per se; it’s standard identity management best practice.
Rogue provider concerns
Request: Mitigate attack related to a rogue provider setting the expiration of the secret key for the association handle and making sure consumers check to see if the secret key is associated with the provider.
Action: None.
Commentary: Without a trust model, there’s nothing to trust! So a rogue provider can act with impunity. If in the future providers only hold and present attributes signed by trusted third parties this would be less of a concern (but other practical architectural issues may come to the fore, like trust chains to those third parties, not to mention discovery of different attribute providers).
Cleartext association keys
Request: Mitigate risk of consumers that negotiate cleartext association keys, which lead to a vulnerability to MITM attacks.
Action: None; our provider does not accept HTTP connections from consumers.
Commentary: Here’s another case that would be solved by thorough and proper use of SSL/TLS. Using HTTP alone, there’s cleartext transmission of cookies and everything else.
If we had our druthers, OpenID would have dictated normalization of ambiguous URIs provided by users into https: form. Both the V1.1 and V2.0 specs are noncommittal on this point, and implementors have chosen to assume cleartext. But as the recent discussion on the OpenID general list (under “Reconsidering http://openid different from https://openid”) shows, the usability issues are tough to surmount whatever you do.
