Password can be seen as plain text

[UdayArikatla]

If I give a Text data item as password output for Get action of Internal credentials. It gives me the plain text. There is a huge possibility security violation and any one in a shared environment can steal my password by just passing a plain text variable as output variable. Can we restrict this to strictly accept password type not the plain text? Also can we mask the data from logs (i.e. data to be stored as xxx-23-xxx in db). We actually want to log the data for troubleshooting at the time of issues. But at the same time we don't want that data to be used/viewed by some others who can access the sql server directly. In short, We want to see the data on the logs but when we go to db it should be masked. Can we achieve that?  

[John__Carter]

Access to credentials should be restricted to particular user roles, processes an resources. They should not be made available to all roles/processes/resources. Access to the Production environment should also be highly secure - developers should not have any access to Production and therefore no access to live passwords. The only passwords anyone can cast in this way should be those in Dev or (non-live) Test. Where UAT uses Live data, the Logical Access Model should dictate that developers have read-only access to processes. Passwords have to be 'castable' so that they can be sent to the target application. Even is it was not possible to perform this cast, it would be just as easy to write the password into Notepad. Even when you type password manually, you are sending plain text to the application.

[John__Carter]

Regarding the logs, there is no mask/unmask switch, the developer must take responsibility to control what is written to the log and to make sure sensitive data is not preserved. The logging of Input and Output parameters can be disabled or the whole stage can be excluded from the logs. Work queues can be encrypted but logs cannot.

[UdayArikatla]

Understand that there is no switch for mask/unmask and we can secure the by disabling the log entry.   My point is, If we restrict the log entry we may not be able to troubleshoot if there is any issue. Logs will help troubleshooting the issue at the same time if the data is stored in the db there can be a possibility that the data can be used by someone else as it is stored in the db.   Instead, If we can log the data and mask it, That will help the troubleshooting problems and also secures the data.

[JohnnyPrescott]

We find this to also be a concern. You often need to have access to the credential anyway as a Dev to be able to debug stuff. Also, as it is setup right now, Blueprism dev / Prod system is not robust enough to be able to separate them completly. anything that goes out a of password dataItem should not stay there for a long period of time. When trying to ""Evaluate"" a password through any calculation, it will return a plain text string. I also agree with the logs.

[John__Carter]

As I've mentioned in a previous post, having only Dev and Prod is BAD PRACTICE. Prod should be a 'lights out' environment that developers don't have any access to, and any Prod credentials should be accessible only to the robots and the Admin. Some clients go so far as to have the robots update their own credentials every day so no human ever knows the passwords. That you are debugging in Prod shows why you need a Test environment. I recommend you seek help from the Technical Architect in your organisation (or your Partner, or your Blue Prism contact) in setting up your environment correctly.

[UdayArikatla]

When I say Troubleshoot, I didn't mean debug. The basic troubleshooting you do by looking at logs to Identify when a production issue/Issue with bad data occurs in prod. Those logs if we can mask before storing in DB is what we are looking for.