Why shouldn't Strong Naming be used for Security?

Question

I've read this claim in many places and had people tell me this directly, but I haven't been able to find a conclusive answer about the full list of reasons why a Strong Name can't be used for security.

I understand the intention of the Strong Name feature is identification rather than security but I'm looking for an explanation of any security problems that can be caused by using Strong Naming for security.

I'd like to know:

• What the CLR does out-of-the-box with respect to verifying Strong Names of assemblies when loaded.
• What are the features of Strong Naming that make people try to use it for security.
• What are the limitations of Strong Naming that make it inappropriate for security.
• What should we do instead to achieve the security that people use Strong Naming for?

What I'm not looking for:

• Limitations of Strong Naming with respect to versioning assemblies
• The problems related to OSS (for example, having to hide the private key and this making it difficult for contributors)

Answer 1

The reason people tell you not to use strong naming for security (I assume you mean integrity checking) is that it no longer works.

Since .NET 3.5 SP1, the .NET assembly loader does not validate the integrity of strong name assemblies anymore. If you want to prevent assemblies from being modified on disk, you'll have to use Authenticode.

These links describe the changes, exceptions and the reasons behind it (startup speed):

• http://blogs.msdn.com/b/shawnfa/archive/2008/05/14/strong-name-bypass.aspx
• http://www.outercurve.org/blog/2014/03/25/Strongnaming-I-Do-Not-Think-It-Means-What-You-Thin/