Password encryption between different versions of Qlik Web Connectors

[stevedark]

Hi,

I am looking to use SFTP to transfer a file to a server on a client site. The FTP server is available on the Internet, and from QWC on my laptop I am able to create a load script statement which picks up the file and places it in the correct place on the server. When I move this to my client's site it fails with the error: Error decrypting value (length 59) for parameter password

The issue that I have is that I do no have direct access to the QWC portal at the client, so have to craft my connector URLs elsewhere and then issue them against the server. Getting the error message involves sending the URL to someone else to run it for me. They don't understand QWC, just paste the URL and send me the result. I can't therefore generated an encrypted password on their server.

The server requires a loadAccessToken, but I don't believe this is the issue, as I have issued other statements using the same key which work fine (SMTP, mostly). In fact these also have encrypted passwords.

The thing I think may be the issue is that they are using November 2018 release of QWC, whilst I am on the latest. I have passed encrypted passwords between versions previously without issue.

Does anyone know if there was a point where the encryption algorithm changed for passwords in QWC?

I did suspect an issue with a quote character in the password, but I have requested a password change and the only contentious character now is a # symbol.

Anyone have any suggestions as to how I can get this working? Getting QWC upgraded at the client is not likely to be a possibility.

Do you have any thoughts @chrisbrain ?

Full exception code below.

Thanks,

Steve

APIConnectorInterfaces.Exceptions.QwcException: Error decrypting value (length 59) for parameter password ---> System.FormatException: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
at System.Convert.FromBase64_ComputeResultLength(Char* inputPtr, Int32 inputLength)
at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
at System.Convert.FromBase64String(String s)
at APIConnectorEngine.Qwc.QwcHelpers.TripleDESEncryption_OBSOLETE.FIPS_DecryptString_OBSOLETE(String Message)
at APIConnectorEngine.Qwc.QwcHelpers.MasterDecrypt(String Message)
at APIConnectorInterfaces.Tables_and_Data.Parameters.ParameterSimple.ProcessValue(String parameterValue, IEncryptor encryptor, FileSystemAccess fileSystemAccess)
--- End of inner exception stack trace ---
at APIConnectorInterfaces.Tables_and_Data.Parameters.ParameterSimple.ProcessValue(String parameterValue, IEncryptor encryptor, FileSystemAccess fileSystemAccess)
at APIConnectorInterfaces.Tables_and_Data.Parameters.ParameterSimple.ValidateAndUpdateCurrentValue(RequestPackage requestPackage, Boolean mandatory, IEncryptor encryptor, FileSystemAccess fileSystemAccess, Boolean updateCurrentValue)
at APIConnectorInterfaces.Tables_and_Data.Parameters.ParameterSet.ValidateAndUpdateCurrentValues(RequestPackage requestPackage, IEncryptor encryptor, FileSystemAccess fileSystemAccess, Boolean updateCurrentValues, List`1 invalidParameterExceptions)
at APIConnectorInterfaces.Tables_and_Data.Parameters.TableSet.ValidateAndUpdateParameterCurrentValues(RequestPackage requestPackage, Boolean updateCurrentValues)
at APIConnectorInterfaces.Tables_and_Data.Parameters.TableSet.ValidateAndUpdateParameterCurrentValuesThreadSafe(RequestPackage requestPackage, Action updateInputs)
at FileTransferConnector.FileTransferConnector.onRequestTable(RequestPackage r)
at APIConnectorEngine.Qwc.WebServer.QwcWebServer.ProcessHttpRequest(ILicenceManager licenceManager, IWebRequestAndResponse reqAndResp, IAPIConnectorWrapper wrapper, AdditionalProcessHttpRequestCfg additionalProcessHttpRequestCfg)

[chrisbrain · Accepted solution]

HI Steve - Yes this looks likely related to security improvements/changes we made - I would encourage them, and anybody in general, to always upgrade to latest version.

Not sure why this is not a possibility for them - the only other suggestion I have - which I don't recommend - is for you to try generating the script using the same version they are running.

[stevedark]

Hi Chris,

Thanks for the prompt response. The team that will do the upgrade are in a different region, and may not be keen to do it. Now that I know it will likely fix this issue (and resolve other security issues) I will push for an upgrade to be done.

The issue I have with generating the script with the version they are running is that when I try and run that version it just advises me that there is a new version and doesn't start correctly.

Many thanks,

Steve

[stevedark]

Hi @chrisbrain 

I've hit another snag with this, pretty much on the anniversary of my first enquiry!

I've just upgraded a client's QWC from a release a couple of years back to the Jun 2021 release. They have an FTP download script which is now failing with an error Error decrypting value (length 69) for parameter password.

I presume this is because the encryption mechanism has changed?

Obviously, all we need to do is re-encrypt the password and all is good. But... they don't know the password at present, or know how to get it changed to something they do know. They also have an urgent need to get these data loaded.

Any suggestions on how we might be able to progress from here. Happy to share the old encyrpted password in a DM if that helps.

Thanks in advance,

Steve

[stevedark]

Found it! Their script had multiple downloads, some using the deprecated password and some using the new style. Was able to use the new encrypted password in place of the old and all worked well. Phew!

Would still be good to know if it is possible to convert from an old QWC encrypted string to a new one without knowing the original password.

Thanks!

Steve