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.
Cheers
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?
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:
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?
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:
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 ?
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.
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?
Anil_G
ashokkarale
jinal.shah
Gautham_Pattabiraman
postwick
chandreshsinh.jadeja
vrdabberu
Ajay_Mishra
sven.wullum1
Vyshnavi_Nalumachu