[Dear XrmToolBox team,
we are currently reviewing how security-related data is stored and protected when using XrmToolBox. During this review, a few questions came up regarding proxy credentials, connection-related authentication data, and access to such information by plugins.
1. Storage of proxy credentials in settings
When configuring a custom proxy in the XrmToolBox settings, it is possible to enter a username and password.
After saving the settings, we checked the following file:
C:\Users<username>\AppData\Roaming\MscrmTools\XrmToolBox\Settings\XrmToolBox.Settings.xml
Show more lines
In our test, the proxy password appeared to be stored in plain text, for example:
<RememberSession>false</RememberSession>
<ByPassProxyOnLocal>false</ByPassProxyOnLocal>
<Password>[proxy-password-stored-here-in-plain-text]</Password>
<ProxyAddress>http://proxy.example</ProxyAddress>
<UseCustomProxy>true</UseCustomProxy>
<UseDefaultCredentials>false</UseDefaultCredentials>
<UseInternetExplorerProxy>false</UseInternetExplorerProxy>
<UserName>AdminUser</UserName>
<LogLevel>Verbose</LogLevel>
<LogRetentionInDays>15</LogRetentionInDays>"
Since XrmToolBox is often used by CRM / Dynamics 365 administrators with elevated permissions, we would like to better understand how proxy credentials are intended to be protected.
Questions:
- Is storing the proxy password in plain text the expected behavior?
- Are there any recommended workarounds or configuration options to avoid storing the password in plain text?
- Are there any plans to store proxy credentials in an encrypted or otherwise protected way?
2. Storage of certificate-based connection information and tokens
This also raised a related question regarding saved connections, especially when using certificate-based authentication.
When creating a new connection with certificate-based authentication, the connection can be saved and later reused without additional manual input. However, unlike the Connection Wizard option 'Save password as encrypted string in connections file, it is not obvious which security-related components are saved, where they are saved, and how they are protected.
We found the following file:
C:\Users<username>\AppData\Roaming\MscrmTools\XrmToolBox\Connections\ConnectionsList.Default.xml
So far, we could see that it contains the username, but we did not identify tokens, certificate thumbprints, or other login-related information in plain text.
Questions:
- Which security-related components are stored for saved connections, for example username, certificate thumbprint, tokens, refresh tokens, or other authentication metadata?
- Where are these components stored?
- Are any of these components stored in plain text?
- If encryption or protection is used, what mechanism is used?
- For the 'Connection Wizard', 'Save password as encrypted string in connections file' option, what type of encryption or protection is applied?
3. Protection of credentials and tokens from tools
Finally, we would like to understand how XrmToolBox protects security-related data from the tools/plugins. Since XrmToolBox supports multiple tools, we are interested in whether the tools added to XrmToolBox can access sensitive information such as saved usernames, passwords, tokens, certificate-related information, or connection metadata.
Questions:
- Are there any safeguards in XrmToolBox that prevent plugins from accessing saved credentials, tokens, or other security-related connection data?
- Are plugins technically able to read the settings and connection files from the user profile?
- Are there any documented recommendations for plugin developers or users regarding the handling of sensitive authentication data?
Thank you for clarifying these points. We appreciate the work that goes into XrmToolBox and would like to better understand the current security model and any recommended best practices for using it safely in administrator scenarios.]
- Connection Controls Version: 1.2025.9.64
- XrmToolBox Version: 1.2025.10.74
[Dear XrmToolBox team,
we are currently reviewing how security-related data is stored and protected when using XrmToolBox. During this review, a few questions came up regarding proxy credentials, connection-related authentication data, and access to such information by plugins.
1. Storage of proxy credentials in settings
When configuring a custom proxy in the XrmToolBox settings, it is possible to enter a username and password.
After saving the settings, we checked the following file:
C:\Users<username>\AppData\Roaming\MscrmTools\XrmToolBox\Settings\XrmToolBox.Settings.xml
Show more lines
In our test, the proxy password appeared to be stored in plain text, for example:
Since XrmToolBox is often used by CRM / Dynamics 365 administrators with elevated permissions, we would like to better understand how proxy credentials are intended to be protected.
Questions:
2. Storage of certificate-based connection information and tokens
This also raised a related question regarding saved connections, especially when using certificate-based authentication.
When creating a new connection with certificate-based authentication, the connection can be saved and later reused without additional manual input. However, unlike the Connection Wizard option 'Save password as encrypted string in connections file, it is not obvious which security-related components are saved, where they are saved, and how they are protected.
We found the following file:
C:\Users<username>\AppData\Roaming\MscrmTools\XrmToolBox\Connections\ConnectionsList.Default.xml
So far, we could see that it contains the username, but we did not identify tokens, certificate thumbprints, or other login-related information in plain text.
Questions:
3. Protection of credentials and tokens from tools
Finally, we would like to understand how XrmToolBox protects security-related data from the tools/plugins. Since XrmToolBox supports multiple tools, we are interested in whether the tools added to XrmToolBox can access sensitive information such as saved usernames, passwords, tokens, certificate-related information, or connection metadata.
Questions:
Thank you for clarifying these points. We appreciate the work that goes into XrmToolBox and would like to better understand the current security model and any recommended best practices for using it safely in administrator scenarios.]