[Enhancement]: Improve MachineKey (update insecure algorithms, add automatic key rotation)

[BeniFreitag]

Is there an existing issue for this?

• I have searched the existing issues

Description of problem

Due to current cyberattacks, the MachineKey should be addressed with high priority.

DNN 10.0.1 still uses <machineKey decryption="3DES" validation="SHA1" /> by default.

1. The current default for decryption in ASP.Net is AES (Source). AES became the standard, see AES-128 vs 3DES-168,
2. The current default for validation in ASP.Net is SHA256 (Source). SHA1 is insecure and should not be used anymore ("not permitted for purchase by the federal government", see NIST).
3. Additionally Microsoft “improved ASP.NET view state security and key management” in SharePoint, by adding an automatic machine key rotation every 30 days, to “minimizing the risk of key compromise” (Details). Such a mechanism should also be implemented for DNN.

Related to:

1. Updates to Default MachineKey Handling #4966
2. SharePoint vulnerability CVE-2025-53770
3. Deprecate or Update Cryptography Classes to Use Updated Encryption and Decryption Methods #3365

Description of solution

1. Change machineKey.decryption to AES
2. Change machineKey.validation to HMACSHA256 (or even HMACSHA512)
3. Create a scheduled task that automatically changes validationKey. It should run by default every 30 days. Similar as Microsoft does it in SharePoint by default.
4. Review whether chainging the decryptionKey can also be automated by a scheduled task. Probably it can't because encrypted settings (PortalSettings, HostSettings) can't be read anymore afterward.

Description of alternatives considered

Anything else?

When chainging the decryptionKey, existing encrypted settings must be set again, since they can't be decrypted/read anymore.
When changing the validationKey, existing login-sessions are invalidated. All users must sign in again.

My assessment is that, considering safety, both should be manageable. Users having a DNN-login must be informed before the change is done in production.

Do you plan to contribute code for this enhancement?

• Yes

Would you be interested in sponsoring this enhancement?

• Yes

Code of Conduct

• I agree to follow this project's Code of Conduct

[BeniFreitag]

Changing the decryptionKey or validationKey seems to also break license activation of certain Extensions, like Document Exchange (DMX) from @donker. License must be reactivated afterward.

[valadas]

Yes and many other extensions also base their licensing "fingerprint" off one or both of those values. I am not completely against this idea (I think it is great for security) but it would needs to have a big big warning on what could potentially happen by doing so.