How to secure Bot passwords

Help
1

Hi guys. My IT/QM is concerned that since multiple employees will have access to the Bot they will be able to see the Bot’s passwords to our enterprise systems. Does UiPath have a way to hide passwords or audit who has seen the passwords the Bot uses. Thanks!

2

This is my opinion, but it’s as secure as a human telling an associate their password themselves via post-it or verbally. You have to really want to get the password to see it, as it’s not just visible. The passwords are all encrypted.

Also, if a password is changed in Orchestrator it shows up in the Audit section, assuming you gave the user access to change Robots or Assets.

Additionally, I would recommend that passwords to applications be separate as Robot passwords, and give ownership/responsibility of the application passwords to the manager that own the process. However, if a password is stored in Assets, an associate could write a process that Gets Credentials and find out what the password is… if they really wanted to, but so can you if you share it verbally.

That’s from what I’ve observed anyway (using UiPath 2017).

CyberArk might be an alternative to password management as well. But seems like the biggest concern is access to network files, because the robots can not process without that kind of access.

3

Hi ClaytonM, thanks so much. It sounds like there are some options. I created a quick visual to explain the question a different way. Based on this do you have any other recommendations!

Bot%20Client%20Portal%20Question|455x423?

4

Use the Windows Vault and its activities on UIpath.

5

Thanks we do not have an issue of savign the passwords, we have an issue with other people have access to passwords. is there a way to prevent this or have an audit trail of who has accessed the passwords?

6

With the Windows Vault there is no easy way to an user get the password in plain text or use it.

7

There is a way to detect the node name of who remoted into a machine through Powershell. I don’t know if that’s really an ideal solution though. But I have something like this so I can tell when users log in and possibly kick off someone else or cause a robot to fail.

8

You can; you can a create workflow that retrieves the Password from the Credential Manager through Get Secure Credential. Then you use the Type Secure Text to type the SecureString in just a notepad and the password is there in plain sight. Just tested it.

However, the user that intends to do this will need to upload this package and assign it to a robot. This will be logged.

1 Like
9

Hi @jkonn

Let’s take an example: if I define an Asset - Credential type => you can retrieve that password if you write a workflow in Studio. For this case I understand your concern.

What I don’t really get is your initial concern:

When a someone builds a process they do it in a development environment - that means they should have dummy/test data. In a production environment the person who knows the real passwords will create the assets and another person who runs the process won’t have access to them. For example, a company doesn’t go to production without a thorough code review - to make sure the process doesn’t retrieve the passwords or call an API that they shouldn’t etc. My point is that you don’t develop in production, so you won’t even have access to Studio (or you shouldn’t).

Also, I don’t really get your request to hide passwords. Could you please detail this?
For “audit who has seen the passwords the Bot uses” - as Clayton mentioned, you have Audit in Orchestrator to see who triggered the Job.

Please let me know if you have any questions regarding my answer.

Thanks,
Viorela

10

When a someone builds a process they do it in a development environment - that means they should have dummy/test data. In a production environment the person who knows the real passwords will create the assets and another person who runs the process won’t have access to them. For example, a company doesn’t go to production without a thorough code review - to make sure the process doesn’t retrieve the passwords or call an API that they shouldn’t etc. My point is that you don’t develop in production, so you won’t even have access to Studio (or you shouldn’t).

This is also more a trust, audit and compliancy issue. When an user is not following standard procedures but is willing (and able) to retrieve the credentials. An user with admin permissions on the production environment can develop a simple process in Studio, upload that package in production and assign it to a robot to retrieve credentials. In theory it is possible, but… If you have admin roles on production you are normally trusted anyway. If it’s really an issue then you should actively monitor which packages are active, which packages were uploaded by whom and when and when these were executed by which robot - by multiple users. And like ovi said, don’t simply open the production environment to everyone. Develop, test, review, document, audit etc.

In addition, you don’t give the robots access to the account credentials of human users. You create specific robot accounts and also limit access to sensitive data through there. In some cases you can even go a step further - depending on your IAM solution - by restricting the usage to a certain VM or IP address. So even when a human user is able to retrieve the credentials , he can’t use them. Also, you can regularly change the password of the robots - or automate this process through RPA :wink: