Fork me on GitHub

Regular security features

  • Full implementation of OpenID's discovery, verification, and rediscovery requirements.
  • HTTPS certificates are validated against CRL (certificate revocation list).
  • XRI resolution using 100% HTTPS.
  • XRIs resolve to CanonicalID (i-number) claimed identifiers.
  • Replay protection when working with OpenID 1.x RP or OP
  • OP: all extensions are always signed.
  • RP: return_to callback parameters signed to protect against tampering.
  • RP: ignores unsigned extensions from OPs by default.
  • RP: replay protection is always provided (except stateless mode). For OpenID 1.1, 2.0, even if using private associations.
  • 490+ unit tests to verify correct behavior in optimal, suboptimal and attack scenarios.
  • Based on .NET platform to protect against buffer overflows and many other attack vectors already protected against as part of the platform.

Optional enhanced security

  • Whitelist/blacklist hosts
  • Require HTTPS for all discovery and authentication.
  • Disallow OpenID 1.x interop (requiring a minimum version of 2.0, for example)
  • Set minimum/maximum bit length for issued/accepted associations.
  • SHA-384 and SHA-512 hashes in addition to the standard SHA-1 and SHA-256 for optional increased security.
  • OP: Configure unique lifetimes to each association bit length.
  • OP: Sample PPID (pairwise unique anonymous) identifier generator to protect privacy of your customers.
  • RP: Filter allowed logins based on OP endpoint, claimed identifier, directed identity, or OP-supported extensions.
  • RP: Reject unsolicited assertions.
  • RP: Disable delegated identifiers.
  • RP: Configure lifetime of private secret used for return_to signing.

Security options are configurable for the whole web site or per endpoint.

Security News bulletins

DNS poisoning + (Debian's) weak HTTPS certificates

A recent security news bulletin revealed that  Debian and derivative Linux operating systems have been generating extremely weak HTTPS certificates for years. As a result, OpenID relying party web sites may be vulnerable to a brute force HTTPS certificate plus DNS poisoning attack to phish users passwords and/or spoof users' identities. The mitigation for this is for the RP's OpenID implementation to check the HTTPS certificate revocation list (CRL) for added security against these weak certificates.

Since DotNetOpenId is based on the .NET platform and leverages its HTTPS security framework, all web sites that use DotNetOpenId can protect against this attack by adding this line to the hosting web site's startup code:

System.Net.ServicePointManager.CheckCertificateRevocationList = true;

Or add this to your Web.config file:

<system.net>
	<settings>
		<servicePointManager checkCertificateRevocationList="true"/>
	</settings>
</system.net>

This requires full trust in your web app, and will unfortunately not work in many shared host environments that give web apps only partial trust.