Comparison of .NET and Java Security

  • Article

Denis Piliptchouk has written a four part series comparing .NET and Java security on O'Reilly's OnJava site.

  1. Part 1 - Security Configuration and Code Containment
  2. Part 2 - Cryptography and Communication
  3. Part 3 - Code Protection and CAS
  4. Part 4 - Authentication and User Access Security

Overall, Denis finds that CAS is a much better system than Java's equivilant system, although he does think that Java is more easily extensible.  He thinks that Java's X509 certificate class is much better than .NET's X509Certificate (which will be rectified with the upcoming Whidbey X509CertificateEx class), but overall the two cryptography systems are about equal, with Java having a slightly more complex class hierarchy due to their initial structuring around United States export restrictions.

Denis also finds that .NET is much better for security when it comes to web services, since Java doesn't even provide a solution there, although he points out that security and remoting in .NET is not up to par.  (Though Microsoft does provide several example implementations of creating a secure sink for remoting).  In terms of verification, Denis thinks that both platforms do a good job, although .NET does provide more checks and an easier environment to use.

One area where I disagree with his article is when he says that every assembly should be signed with a different strong name.  I tend to think that all assemblies from one company (or one product) should be signed with the same key, making CAS policy easier to setup.  For instance, if I know that I'm always going to trust code from Adobe, and they have one company key, it's very easy for me to add a custom code group providing full trust to that key.  However, if they use a different key for every assembly, I'm going to have to add many extra code groups.  The problem gets worse if there are new assemblies in the next version of their product; possibly causing SecurityExceptions after the upgrade, since these new assemblies will not be trusted at the same level as the rest of the application.

Updated: (2/27/04) Added the link to the recently posted part 4.