Is there an existing issue for this?

• I have searched the existing issues

What happened?

Starting in DNN 10.2.2, the value returned from PortalSecurity.EncryptString cannot be decrypted.

Steps to reproduce?

This API is not used by DNN's core code, so steps to reproduce include creating some kind of custom extension, calling PortalSecurity.EncryptString and then passing that value to PortalSecurity.DecryptString.

Current Behavior

A FormatException is thrown when attempting to decode the message.

Expected Behavior

The encrypted value should be decrypted successfully.

Relevant log output

Anything else?

From a report on Discord by Sander:

Something else, same subject. sounds strange to me.

We use EncryptString and DecryptString in custom code to save encrypted in sql.

now all data in the SQL decrypts just fine and so far oke.

Now if we save or update this and thus use EncryptString to save to db encrypted things go wrong.
The new values give bad data when running through DecryptString

So things encrypt but are not decryptable.
but old data is still decryptable

The error seems to be in obsolete portalsecurity. encryptstring will follow new way and decryptstring is still old way >and will send null for the init vector

we think it started with 10.2.2 .. site that is still on 10.1.X does not have this issue.
and it looks like we can solve it by leaving portalsecurity but the bug/mismatch there does cause a problem because it looks like the data saved since 10.2.2 up untill we leave portalsecurity (only for fallback on old saved data from before 10.2.2) has to be re entered again
is will not be decryptable ever again I think
this is kind of big for us as it will delay updates on 10.1.X to latest dnn untill we change all custom encrypt/decrypt code

and difference with fileticket is that that one uses DecryptParameter and we use DecryptString

so it looks like encryptstring and decryptstring is not usable anymore unless also saving IV returned data with the >encrypted string (from tuple) ? this makes it allmost unusable for us.
alternative might be doing the same as dnn does for hostsettings. so using the FIPSCompliant.EncryptAES and FIPSCompliant.DecryptAES wich will fallback to portal Guid for the IV (or salt if you want to call it that)

Affected Versions

10.3.1 (latest release)

What browsers are you seeing the problem on?

No response

Code of Conduct

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