title: Secure Handling of Connection String for Delphi's TADOConnection object
body: <p><strong>The Environment</strong></p>
  <p>I have a 30-year-old Windows desktop application written in Delphi 10.4 (upgraded numerous times throughout its life).  It has a TDataModule with approximately 100 TADOQuery, TADODataSetProvider, TClientDataSet, TDataSource, and other related components.  There is only one TADOConnection component for the entire application.  These components are chained together at design time so that the only value that needs to be set at runtime is the TADOConnection's ConnectionString property.  Also, the connection string has &quot;Persist Security Info=True&quot; in it.  This has been working great for decades.</p>
  <p>We recently added a custom class (TSecureString - to mimic C#'s SecureString class) to store sensitive string data in a format that was unreadable in memory.  The connection string that we read from an INI file is stored in memory as TSecureString.  It is only converted back to plain text when assigning it to TADOConnection.ConnectionString.</p>
  <p><strong>The Problem</strong></p>
  <p>Corporate IT did a security scan and said they could see our plain text connection string in memory.  The security scan report said that this plain text connection string was in memory even when the program was just sitting on the main form right after logging in, not doing any SQL calls.</p>
  <p>I've seen numerous posts (like <a href="https://stackoverflow.com/questions/47951499/hide-connection-user-password-in-memory-in-delphi-tadoconnection">hide connection user password in memory in delphi TadoConnection</a>) that say to use TADOConnection's OnWillConnect property to change the user id and password.  This seems ideal, but we only set the Connected property to True once during login.  If Connected is not set to True, then every time any of those 100 components are used, they would need to have Connected set to true first.  This seems unreasonable considering 1) how the components were designed, and 2) the sheer volume of code that would have to change.  Additionally, none of these posts state how to remove the user ID and password after one is done with the execution.</p>
  <p>Using the OnWillExecute event would solve the above issues, but changing the Connection parameter's ConnectionString property results in the error &quot;Operation is not allowed when the object is open.&quot;, which is reasonable.</p>
  <p>Also, changing the connection string to &quot;Persist Security Info=False&quot; won't work (AFAIK) because the user ID and password need to be set when Connected is set to true.  There doesn't seem to be any way to change these value at the components' SQL execution time.</p>
  <p><strong>The Ask</strong></p>
  <p>What is the technically best, correct way of using TADOConnection globally while still hiding the connection string in memory, since it appears that the TADOConnection object doesn't do that by itself?</p>
  <p>If you think that the TADOConnection object does hide/encrypt the connection string in memory, then please provide documentation to that effect.  I could not find anything one way or another in this regard.</p>
  <p><strong>Caveats</strong></p>
  <p>Please do not provide answers with <em>generic</em> best security practices with connection strings, databases, or web-based solutions.  It's a desktop application working with a database on a LAN.  Also, this application is being sunset, so major overhauls of this nature won't be done.  This question is about the right way to use the TADOConnection component securely.</p>