Session manager not saving password with non-ASCII characters correctly

[WarstekHUN]

Preconditions

• HeidiSQL version: 12.5.0.6680
• Database type and version:
  • 10.4.27-MariaDB
  • 11.0.2-MariaDB
• OS: Windows 10 Pro x64

Describe the bug

I have the correct auth information stored in the session manager. Every time I want to connect to my db, the server declines my password. Here comes the fun part: If I type my password in manually (or just paste it in) I can connect to my server. This problem only consists with my server. Is there a hidden option in MariaDB that I forgot to toggle or is this a HeidiSQL bug?

To Reproduce

1. Try to connect to a (TCP/UDP) MariaDB (libmariadb.dll) server via the session manager with username and password already stored.
2. After it throws access denied copy the correct password and paste it in to its corresponding field.
3. Try to connect again. This time, you'll be able to.

Screenshots or Crash reports

[ansgarbecker]

Your password likely contains characters which get broken through my obfuscation logic used when storing it in your registry. Reading out such a broken password results in a wrong password, which then is rejected by the server. I recommend to either change the password to something without non-ASCII characters, or just don't store it ("prompt for credentials" option). It's unlikely I can fix that without breaking previously stored passwords, but I will see.

[QcFe]

I have the same issue accessing a MSSQL db. When I restart HeidiSQL the password field misses a bullet all the times. Likely, using Windows' integrated password wallet (or b64-ing the string before processing it) could be of use...

[WarstekHUN]

Your password likely contains characters which get broken through my obfuscation logic used when storing it in your registry. Reading out such a broken password results in a wrong password, which then is rejected by the server. I recommend to either change the password to something without non-ASCII characters, or just don't store it ("prompt for credentials" option). It's unlikely I can fix that without breaking previously stored passwords, but I will see.

Just changed my server's pass for security reasons. I have generated it to only contain ASCII characters. Your theory is proven, it works now.

About fixing the bug

Wouldn't it be a good fix to let the user choose between the old and the new obfuscation method? For example the default obf. method would be the new and It could be changed in the Advanced tab in the Session Manager?