We have a module where we used to encrypt some parameters with something like this:
string serialized = serializeParameters(); string qs = DotNetNuke.Common.Utilities.UrlUtils.EncryptParameter(serialized); return QS_NAVIGATE + "=" + HttpContext.Current.Server.UrlEncode(qs);
This was the used on a URL similar to www.domain.com/somepath/encryptedparams=xxxxxxxxxxxxxx
This was working fine until we moved to DNN 10. Now all previous urls that were generated are broken, if we run the same code on DNN 10, we get a different encrypted string.
Is this a known feature? Because I'd consider this a breaking change.
Are you running DNN10 on the same machine? Is your ASP.NET machinekey the same?
https://learn.microsoft.c...view=aspnetcore-10.0
Yes to both. It was a standard DNN upgrade and the machine key didn't change.
In case it helps... an AI generated response, so may not be entirely accurate...
Yes, older and newer versions of <code>DotNetNuke.Abstractions.Security.ICryptographyProvider.EncryptParameter</code> will produce different encrypted results.
The core reason is that the underlying encryption implementation has changed across DNN versions to fix security vulnerabilities, not because of the interface definition itself. Here's a breakdown of the key differences:
DNN versions 9.2 through 9.2.2 were found to use a weak encryption algorithm to protect input parameters. Additionally, these versions incorrectly converted encryption key source values, resulting in lower-than-expected entropy.
To fix these issues (CVEs), DNN had to update its encryption implementation in later versions. The fixes were incomplete in some cases, leading to further changes. This means the actual encryption logic—and thus the output—changed between versions.
<code>EncryptParameter</code> relies on the machine key configured in your <code>web.config</code> file (specifically, the <code>ValidationKey</code> and <code>DecryptionKey</code>).
Older DNN versions often shipped with default, embedded machine keys in their <code>web.config</code>.
Newer versions, especially those addressing the CVEs above, have updated their default machine key handling and best practices.
If the machine key used for encryption differs between your old and new environments, the encrypted output will be different, even if the code logic were identical.
<code>ICryptographyProvider</code> is just an interface (contract) defined in the <code>DotNetNuke.Abstractions</code> assembly. It doesn't contain any encryption logic itself. The actual encryption is performed by a concrete implementation of this interface, which is part of the DNN Platform's core library (<code>DotNetNuke.dll</code>).
As the platform evolved, these concrete implementations were updated to use stronger algorithms (like AES) and better key derivation practices.
Do not rely on <code>EncryptParameter</code> for cross-version compatibility. It is not designed to produce consistent, version-agnostic encrypted strings.
If you need consistent encryption across environments, implement your own dedicated encryption method using a stable algorithm (like AES) with a fixed, explicitly managed key and initialization vector (IV) that you control.
When upgrading DNN, be aware that any encrypted parameters generated by the old version may not be decryptable by the new version, and vice-versa. Plan to re-encrypt any such data as part of your upgrade process.
In short, the answer is a definitive yes—older and newer versions will produce different encrypted results due to fundamental security fixes and implementation changes within the DNN platform.
This response is AI-generated, for reference only.
That's helpfull, thank you!
These Forums are for the discussion of the open source CMS DNN platform and ecosystem.
For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:
Awesome! Simply post in the forums using the link below and we'll get you started.