Comparison of .NET and Java Security
Denis Piliptchouk has written a four part series comparing .NET and Java security on O'Reilly's OnJava site.
- Part 1 - Security Configuration and Code Containment
- Part 2 - Cryptography and Communication
- Part 3 - Code Protection and CAS
- 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.
Comments
- Anonymous
February 18, 2004
A comment from the author:
What you're disagreeing about is actually addressed via different mechanism - .NET does support publisher's certificates, and they behave exactly as you are expecting.
As for the strong names - they're cryptographically strong variants of usual file names, which makes them unique in the global space. In order to preserve this uniqueness you have to create a new keypair for each separate assembly - much like a SSN unambiguosly defines any person in US. - Anonymous
February 18, 2004
While I agree that publisher certificates do solve the problem I mention, there are two drawbacks to relying on them.
1. They cost money to get -- individual developers and hobbyists tend to not have certificates, and use .snk files to sign their assemblies. I may want to just trust everything someone has written, I wouldn't want to trust each assembly seperatly.
2. They expire, which means that I would again have to setup a new code group for each publisher every so often. This may not be the biggest pain, however it will over time lead to a large mess of code groups in my policy.
That being said, using certificates is a viable solution, especially for my Adobe example, and not one that I have any problem with. Also, when ClickOnce ships and becomes more pervasive, this problem will go away (since ClickOnce will manage trust decisions on a per-app basis, and I won't have to manually trust each assembly in an application). - Anonymous
February 24, 2004
The comment has been removed - Anonymous
August 17, 2005
It's been a while since I've last seen a comparison of Java and .NET security.  Nathaneal Paul and...