Our application has <machineKey> in web.config :
<machineKey validation="HMACSHA256" validationKey="some-validationkey" decryption="AES" decryptionKey="some-decryption-key" />
It is used to encrypt / decrypt many things built into ASP.NET, including:
- Form Authentication Tickets
- Anonymous ID tickets.
- Anti-fake tapes (in ASP.NET MVC)
If a machine key is cracked, it means that an attacker can decrypt all these things. A best security practice is to often rotate your keys (or at least when you think it might be compromised). This will require the ability to release each piece of encrypted data so that rotation is possible if necessary.
If you change the machine key and redeploy your site, your existing users who have encrypted data (for example, cookies, form fields) will most likely throw exceptions from their next request because the data can no longer be decrypted. For example, AnonymousIdentificationModule will throw a CryptographicException: Error occurred during a cryptographic operation. . This makes sense if AnonymousIdentificationModule not able to decrypt encryption / decryption.
One of the methods that I was thinking about using is to implement custom HashAlgorithm and SymmetricAlgorithm with built-in version control for delegation to real algorithms. For instance:
Register them with CryptoConfig.AddAlgorithm() :
CryptoConfig.AddAlgorithm(typeof(MyCustomHashAlgorithm), "MyCustomHashAlgorithm"); CryptoConfig.AddAlgorithm(typeof(MyCustomSymmetricAlgorithm), "MyCustomSymmetricAlgorithm");
Change <machineKey> to use a custom algorithm:
<machineKey validation="alg:MyCustomHashAlgorithm" validationKey="some-validationkey" decryption="alg:MyCustom" decryptionKey="some-decryption-key" />
However, I am concerned about the implementation of HashAlgorithm and SymmetricAlgorithm . I don’t want to accidentally inject security holes, and this is a simple place to do this. Also, this seems like a huge hack, as it really belongs to a place that uses the algorithm (I think).
Another approach is to reimplement all functions that use a machine key, but add version control. Cannot modify existing .NET classes.
How do you deal with this problem in the manufacturing process? I know that StackOverflow is written in ASP.NET MVC, so how do they handle this?
Note: for security reasons, we do not actually store <machineKey> in web.config directly (it is out of source control).