'Send SMTP Mail Message' Password - SecureString

is there any solution?

I would say that this should be high priority. It’s hard to explain to clients how UiPath takes security seriously when the passwords are stored in plain text.


I’m also looking forward for a solution.
@badita Thank you for the suggested workaround :slight_smile:

1 Like

Meanwhile, I have written a workflow for this that safely stores the password in the Windows credential manager at the first invocation (similar as you do for a general logon):
SendMail.xaml (22.0 KB)

1 Like

Really hoping for SecureString input in SMTP mail activity, we use this to send e-mails from the robot user, and users (process owners) have access to Orchestrator to manage their projects assets.

1 Like

What I did as a workaround is created another extra string variable for password like “StrPassword” and it Solved my Problem

Follow these steps
Create a Variable StrPassword

Then taken a assign activity and assign value for StrPassword

And in value typed the string as

“new System.Net.NetworkCredential(string.Empty, password).Password”

Where “password” contains your secure string that you get from orchestrator assests or windows credentials


One other thought, you do not need to create a String Variable or use the Assign Activity, you can simply put the following statement into the SMTP Password Property (Field):
“new System.Net.NetworkCredential(string.Empty, password).Password”


I notice that Password field in mail activities like Get IMAP Mail Messages and Send SMTP Mail Messages are just String instead of SecureString.

This is disadvantageous. First of all it reveal password*. Secondly it disallow centralization of asset data. For example, I cannot centrally store password on Orchestrator and use Get Credential activity to retrieve it.

Please kindly consider making change to these activities by changing Password field data type from String to SecureString.


*There is similar question about encrypting password. One recommendation is to use GetPassword activity but the output string is still totally visible.


This is a known issue for a long time. Not sure whether there are plans to change this @badita.

There is a workaround as you can pass as a secure string and only convert at the very last instance prior to entering the string into the activity. The only risk here is if someone is able to get on the machine, amend the process to log that value and also run the process. Given the controls around the machine and the Orchestrator this is a pretty low risk in my opinion.


1 Like

Thanks for your input. I manage to get asset’s password from Orchestrator and pass on to send email activity. As you can see there is no proper solution to protect secure info as long as we have to convert a SecureString to String value.
I look forward to having this fixed.

1 Like

Closed as duplicate:

Hi guys, it’s been a while, but I am daring to bring this up again…

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 SecureStrings are passed as arguments to variables. 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?

Sorry again for the revival of this ghost of the past.

EDIT: As this thread seems indeed dead, I have opened a new topic regarding this issue here: Best Practice SecureString in plain string credential property fields

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?

1 Like


As I wrote in above linked post:

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

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?

Cheers, Lukas.

1 Like

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 be used as linked from the SecureString class documentation.

Saying “requiring the conversion to a string will result in the contents being exposed” is a good example of the name “Secure” implying security where it doesn’t actually exist. SecureString does not in anyway protect the contents of the SecureString from being accessed by a legitimate user on the machine. The contents of the SecureString are stored unencrypted in memory in plain text during the lifetime of the SecureString object. What SecureString string does is make sure that when it goes out of scope, the contents are erased, they don’t have to wait to be garbage collected. This has some value in a server process that is taking things like passwords from users, so if a hacker is able to collect a memory dump there will be less out of scope values available that are waiting to be garbage collected, but it doesn’t protect anything that is in scope.

The more important things to account for when designing a process that uses passwords are:

  • Make sure passwords are never stored with the source of the process (e.g. Uber was hacked because credential information was checked into source control).
  • If a password is very sensitive such that you don’t want a developer to have access to it, make sure it’s retrieved in a way that allows different values to be used during development vs. in production, and ensure only the production team knows the production credentials
  • Ensure good practices of what the automation does with the password. Whether it’s stored as a string or a SecureString the more important thing is understanding what the automation is doing with the password. A “Type Secure Text” activity will type the contents into any field. It’s much more likely to have a security problem due to typing secret information somewhere it shouldn’t be (e.g. into some field that ends up in a plain text log as happened to Twitter) than someone getting the value from process memory between the time it was disposed and actually garbage collected.
  • For extra sensitive things, use frequent credential rotation

I haven’t tried this all the way yet as I was trying password.ToString in the SMTP password field - which didn’t seem to work (and if I pound my email with too many failed logins I am going to get blocked), but this looks elegant.

Perhaps I am being too much of a perfectionist but I am trying to ensure all my workflows have NO errors or warnings when I use Analyze file - I get two errors on this or the previous approach and have scoped my password variable tightly and made SMTP private. Perhaps UIPath could address this if Analyze is used alot in projects or should I not care too much what Analyze file tells me ?

Hey @simonpfrank - UiPath did provide some answers in the other (linked) thread regarding Workflow Analyzer and Governance. See this post:

Thanks @lukasziebold. Have read the post you kindly provided. For me it looks like the rule in the anlayzer is a bit overzealous (because the securestring variable is the only variable (there is no text equivalent in variables and it is only converted inside the SMTP (using the method proposed in the original thread) and it is scoped very tightly and the SMTP activity is private, BUT for me that is OK. it highlights the use of the securestring so from a governance perspective this can always be checked.

Am I right ? i.e. there is no way to get the analyse error to go away (or is there) ? - this is just for general knowledge and best practise knowledge.

You’re welcome!

The way I see it, the analyze error with SecureString only goes away, if you don’t use the inofficial “Best Practice for plain string credential property fields” and instead use plain string variables or values.

I find that very painful, because the workflow analyzer doesn’t incentivize the proper usage of SecureStrings:

  • Retrieve SecureString and convert it for the credential property field as recommended: Error ST-SEC-009 (Potential SecureString Misusage)
  • Insert the credential as plain string: No Error.

As cclements said:

I don’t know what’s next. Maybe we need an idea in the UserVoice section?