Security Concerns!

Help
1

@badita - One of the user has raised a ticket regarding Security.

Here is the question raised on forum as well from another user.
Could you please help here ?

My Development team and I are currently reviewing security considerations around our workflows, and one of the potential issues we have raised is the accessibility of passwords from the Windows Credential Vault using UiPath.

Currently, while UiPath ‘Get Credentials’ can return a password as a ‘SecureString’ from the Vault, this can be converted to ‘String’ with an ‘assign’ activity and some code provided by UiPath in a previous forum post. The password is then easily visible and can be written to console/logs etc.

There also does not seem to be the option to maintain the password as ‘SecureString’ for all purposes, if the conversion from SecureString to String was somehow blocked/prevented- while there is a ‘Type SecureString’ activity, passwords in ‘SecureString’ format cannot be inputted in an Excel Application Scope.

Do the UiPath team have any advice/best practice on how to maintain the security of passwords when ‘Getting’ them from the Windows Vault?
Is there a long-term strategy for use of credentials and relevant activities/code within workflows that will maintain the security of passwords when they are inputted into a workflow? Specifically, is the conversion from SecureString to String going to be a permanent capability in UiPath Studio, or temporary measure before something more secure is implemented?

1 Like
2

This is an excellent question and here is how UiPath mitigates it in enterprise deployments.

1. Release Cycle
Every workflow that goes into production needs a reviewer approval (the reviewer is the one who pushes the workflow via Orchestrator). Now, he should check how all the SecureStrings are used…to make sure that SecureStrings are not entered into notepad and sent via email. That’s easy using Search.

2. Source Control
You can track the developer that entered malicious code within the workflow

3. Dev/Test/Production environments
While a dev may call GetCredential within Dev environment he does not have access to production machines. The Dev has access only to TestCredentials.

You have the same problem in software development. How do you make sure that some dev is not introducing malicious code into iOS? The answer is code review, automatic or not + source control.

1 Like
3

Thanks for the response Mihai.
However, if the excel has password i cannot use Secure String as it takes only String. How can we go about this ?

4

You keep the password in a Credential and convert the SecureString to string.
You’ll still using the SecureString type.

5

@badita Yes you are right about the security measures. Since the target application like Excel or SMTP expects the password to be entered in actual password string, so the risk of exposing password is always there and can be stopped by code review and different Dev/Prod server.

But here in UiPath as you are basically using wrapper in form of drag and drop activity for Excel or SMTP email, you may think about two below solutions to remove the need to pass the password string. It will make your product much better.

#1 - In the Excel or SMTP activity (or any activity which require a password string to be entered) you can change the datatype to SecureStringfor password fields. This will make sure that the developer is passing the Secure String variable instead of converting it into string which will make the reviewers life easier.

#2 - Create a UiPath special data type more like SecureString (lets say UiPathSecureString) and use it in all password fields of activities like excel or SMTP. Now do not allow the developer to decrypt the password (which is allowed by SecureString datatype). Inside the Excel or SMTP activity code, get the actual password string and do the activity.

This will restrict the developer to log/email the actual password.

Let me know your thought.

Regards,
Amalendu