Best Practice SecureString in plain string credential property fields

Hi guys,

I have been cleaning up a project and used the workflow analyzer to check for rule violations. Turns out several Potential SecureString misusage were detected.

The SecureString type should not be used for any purpose other than the intended. Scope of these variables should be very limited, ideally in the same scope where they were created. Learn more.

I tried to make the activities using plain string credentials as safe as possible (mail and OCR activities). I marked all relevant activities in GetAppCredentials.xaml and the other workflows as Private and only the SecureString is passed as argument to variable. In the password property of the activities I used the “new System.Net.NetworkCredential(string.Empty, password).Password” workaround.

My question now is: How relevant is the variable scope for the safety of my variables?

Sometimes I’m using more than one activity in question in one workflow, but invoke GetAppCredentials.xaml only once and “share” the SecureString in the wider scope. Do I need to build small sequences where I get credentials and execute the activity and have the SecureString only in that very small scope? If so, what are the benefits to that beside, pleasing the Workflow Analyzer?

Cheers

Hi @lukasziebold,

The Workflow Analyzer is looking for specific coding patterns and using a SecureString beyond a limited scope raises a flag. Imagine you are in a sub-module of a process where you allow an end user to retrieve values from memory and you have opted to keep the SecureString in memory at a broader scope for convenience. If something is coded wrong or a bug is encountered, that end user may have access to the SecureString and/or the plain text value.

From a performance standpoint, if your SecureString is being retrieved thousands of times throughout a process, there could be a performance hinder on the system vs retrieving the SecureString once and storing it in memory so it can be used multiple times.

I would favor security over convenience and performance, especially since the SecureString has to be converted to plain text and I doubt you are retrieving it thousands of times in a single process.

Thanks

Hi @Kristopher,

thank you for your comprehensive answer!

As I’m only retrieving SecureStrings a couple of times, I made changes to all the instances and put a separate sequence and invoke of GetAppCredentials.xaml with each activity using a credential and limiting the scope of the variable to that small sequence. While it is/was a small inconvenience, the SecureString usage now feels more structured and standardized.

However, the Workflow Analyzer still raises flags about potential SecureString misusages. Specifically about the variable/argument Password. I assume this is referring to the value in the Password property:

System.Net.NetworkCredential(string.Empty, MySecureString).Password

I am attaching a screenshot and also linking the (incomplete) history of SecureString usage best practices in plain string credential property fields: 'Send SMTP Mail Message' Password - SecureString

Now, am I missing something? Is this password variable accessible somewhere else? Why am I still getting the SecureString Misusage flag? Is there a better workaround to deal with plain string credential property fields? What about that idea of making credential property fields require a SecureString?

Thank you again for your time and expertise.
Cheers

Hi @Kristopher,

would you mind taking another look at my follow-up questions?

You might also want to address @cclements concerns:

Thank you
Cheers

Thank you @AndrewHall for sharing some valuable points in your reply to above linked thread. I am adding it here to add context:

I’m happy UiPath will evaluate this issue going forward. Would you mind taking a look at my follow-up questions?

Is the password variable accessible somewhere else, when I convert the SecureString to String?
What about the Workflow-Analyzer/Governance issues?

How can I use alternative authentication methods like certificates or auth tokens as recommended by Microsoft in activities like Send Exchange Mail?

Can I access the current users credentials without storing and retrieving them? For example with API calls, I can just use WebClient.UseDefaultCredentials.

Thanks in advance!

Tagging @Corneliu_Niculite regarding questions around certificates or auth tokens with email.

Regarding the other questions:

  • “If the SecureString is converted to a String is it accessible somewhere else”: Normal variable scoping rules apply. For e.g. if you do the conversion directly as the property input, there is no variable created and it’s not accessible anywhere else. Per my explanation it will create a string that resides in memory until the next GC, but no other activities can access it, you’d need a debugger to to searching in process memory. However if the SecureString is still in scope, this isn’t interesting at all because the value is still unencypted in memory in the SecureString variable. So as I explained in the previous post, the security implications of how the password is stored in memory (string vs SecureString) are very likely to be non-interesting in the case of RPA and the other security patterns I outlined are much more important and high priority.
  • What about the “Workflow Analyzer/Governance issues”: Using a SecureString conveys intent, meaning that the contents are likely important. Unfortunately, the misconceptions about what SecureString actually does are extremely prevalent (e.g. comments/questions on this forum and stack overflow constantly refer to “encryption”). The Workflow Analyzer rule was created based on customer demand, and it can make sense in specific scenarios. However for the most part when working with our Enterprise customers I’ve been recommending they not set organizational policy around this for the reasons discussed. Being careful with a password is important, but the type of variable storing the password isn’t in most cases (e.g. as I reference in that post Microsoft recommending not using it even though they brought it to .NET Core for compatibility reasons). Conversion of a SecureString to a string is signal you should double check that is what you really want to do (e.g. once converted to a string, I can do things like write into the logs which is bad), but the in memory representation itself isn’t the real issue, just the warning that it makes it much easier to make a mistake.
  • “Can I access the current users credentials without storing and retrieving them”: Whenever you pass a value to a property, you can execute a single line of code that returns the expected type. If the credentials are stored in a way that can be retrieved in a line of code, then this is possible.
1 Like