Best Practice SecureString in plain string credential property fields

[lukasziebold]

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

[Kristopher (Kristopher Kim)]

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

[lukasziebold]

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

[lukasziebold]

Hi @Kristopher,

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

@lukasziebold

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?

You might also want to address @cclements concerns:

'Send SMTP Mail Message' Password - SecureString

What’s odd is that they seem to be concerned with the improper use of the SecureString and yet have activities that accept passwords as plain text, such as the Send Exchange Message. If you are getting your credentials from an asset, you are forced to cast it to string to use these activities. This will trigger the analyzer error. Solo developers can just disable this rule. But what if you are enforcing a governance policy at the enterprise level?

Thank you
Cheers

[lukasziebold]

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

'Send SMTP Mail Message' Password - SecureString

It’s important to understand what SecureString can and can’t do. Yes, it isn’t a great story that different activities require different inputs (some require SecureString and others require a string) and this is something we will evaluate going forward at UiPath. However, even Microsoft in their official docs now discourages the use of SecureString as it does very little to improve security in most cases and the name implies security where very little is added. See the Secure string shouldn’t b…

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!

[AndrewHall]

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.

[vinodhvictor94 (Vinodh)]

But we still get red flag from workflow analyzer if we use as posted by requestor,the way of Converting secure string to string is valid but still flagged. Any solution on this point of view

[lukasziebold]

Something happened!

All mail activities accept SecureString as input for the password, i.e., they got a new field called SecurePassword in addition to the existing Password field.

From the last Preview Release:
https://forum.uipath.com/t/uipath-community-21-2-preview-release/294491#mail-activities

Cheers!

[pere]

Hi,

I arrived in this thread because I’m experiencing a similar issue to that one of @lukasziebold and I cannot get rid of it.

I have a sequence with an FTP activity that’s causing me problems and I want to try it in an “isolated way”, that is, right click → “Test activity” (after opening it in its own tab; the one I want to try has the “Seqüència - Còpia per SFTP (no “interactiva”)” title in the attached screenshot).

Everything seems to go to work smoothly, the “Continue” and “Stop” buttons in the “Debug” tab are on now and then I see a warning message over a yellow background that I interpret it means I must fill in the required Variable values on the “Locals” tab to the left, in order to be able to test the sequence, which I do, but then, when I press F11, the same yellow window displays the text:

“The workflow has validation erros. Review and resolve them first”.

Which surprises me because the code prior to that always ran smoothly during a debugging session, and I can’t find any nearby error messages or issues.

So I try F7 or Shift+F7, as suggested in some posts I found here (after having to stop the debugging session, which is also a pity).

And then I get the offending message “Error ST-SEC-008 SecureString Variable Usage SecureString variable used outside of the creation scope in FTP Scope.”, which recommends that “Once a SecureString is retrieved, it should be used to log into the applications by using the Type Secure Text activity for normal applications or the Send Keys Secure activity for Terminals. The credential 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. This means arguments should ideally not be used to pass credentials to one workflow to another and variables containing credentials should be defined at the narrowest scope possible.”

But I can’t further narrow the scope of the password variable, which is defined in the surrounding common action to Get Credentials and the FTP Scope activities, and the FTP activity is neither an application or a terminal where I could “type in” any text or passwords.

Furthermore, I wonder if, after getting this of that “error” (which is also confusing, because the program was working before even with this one and further “errors” after an F7, so it sounds to me more like a “strong warning” or so - I mean, they let the app run) I’ll be able to run the activity, or seqüence, in that “isolated” scope I was intending to with the “Test Activity” option…

[pere]

@pere

Furthermore, I wonder if, after getting this of that “error” (which is also confusing, because the program was working before even with this one and further “errors” after an F7, so it sounds to me more like a “strong warning” or so - I mean, they let the app run) I’ll be able to run the activity, or seqüence, in that “isolated” scope I was intending to with the “Test Activity” option…

Ok, I’m replying to myself after changing the validation severity from “Error” to “Warning”, just to realize that, even after doing that, the IDE still complains about ““The workflow has validation erros. Review and resolve them first”.”, but I can’t find any.

[brunoazev (Bruno Costa)]

Hey Community folks,

I’m bringing back this thread from a year ago. I’m using Studio 2023.10.4. The SecureString analyzer is giving me an error even though my Get Credential and Type Secure Text activities are in the same limited scope. I tried changing the depth value of the SecureString analyzer setting to the max of three, but that didn’t work. Anyone know if this is a known issue, and if so, is there a workaround other than changing the setting to “warn”?