Password gets reflected into Text data item

[Akhlesh_KumarJi]

Hi team, I found one bizarre result with the attached flow. I had defined the encryption scheme and Credentials in System manager. Using calculation stage I am able to convert the encrypted password into the Text data item. This is something I am confused because password should not get convert into text data item. Passwords are no longer protected. Please validate/confirm my understanding. Thanks.

[david.l.morris]

The encryption scheme is used to encrypt data in the database and decrypt it before sending to the Runtime Resource. The feature of masked passwords is distinct from encryption. You see dots, but the password is still underneath. When the passwords get logged into session logs, it also is just a set of dots. So, when you use a write stage to write a password data item into a website's login screen in the password field, Blue Prism is not decrypting the password at that point, it is simply writing the data that has already been decrypted on the app server.

[BenKirimlidis]

Hi akjindal,   Yes, we've seen this too.  Seems bizarre but as David points out, there is a logical reason behind.  Still seems as though it shouldn't be possible as you could easily expose a password to the control room by doing this. Utterly bizarre but yes you can definitely view any password datatype data item including any credentials if you have access to edit/create a process and start pulling credentical data.

[Akhlesh_KumarJi]

Thanks Morris, I understand the concept now. But In terms of security there is a huge impact. One developer can expose all the passwords stored in the Blue Prism environment. Many clients are using CyberArk secure vault for security reasons. But when passwords are exposed to Blue Prism developer can see the password easily. I am not convinced the way the passwords get convert into text using calculation stage. Your thoughts? Thanks.

[CC]

I agreed with last comment of Akjindal. Would like to have some thoughts Thanks. 

[david.l.morris]

I agree that it is a concern, so I'll mention a few thoughts to contribute to the discussion. I'm not saying this will solve it all for you. First, in my opinion, no passwords should be used in a Development environment that developers should not have access to. That is, I'd always use test accounts and passwords that only grant access to test systems. I understand this isn't always possible, but usually there's a way to limit the liability there. Second, any implementation of RPA should be accompanied by a thorough review and code promotion/change management procedures. Yes, a developer could set up the process in such a way that a password could be revealed in Control Room in the tags of queue items, in the session logs, etc. But this would only occur in the development environment as long as there is a separate person or persons reviewing the code and ensuring the best/compliant practices are followed. This kind of thing should be caught during SIT or UAT and never reach PROD. Compare it to traditional application development. The same thing is a concern. A developer can absolutely build in code that would reveal a production password. That's why a review of the code itself and a review of the output of the code is necessary. This is also part of why the usual change management process is such that a single person cannot develop a process and then also put it into production. I think that a primary reason that it works the way it does is that passwords often need to be entered into systems in a variety of ways. Write stages are not the only way passwords are entered. Send Keys and Send Key Events are often the only way to enter values, and because of that there would need to be an expansive capability across Blue Prism's actions to be able to decrypt values at the last moment. You'd have to consider other situations as well such as using APIs. There's no stage that puts the password into a field somewhere. Instead it is combined into a message that is sent to a server. Regardless, I agree that it is a feature that Blue Prism needs. It is too easy to accidentally set the datatype of an element in app modeler to Text instead of Password, for example. And then when you write the password into the field, the unmasked password is stored in the session logs. We should probably request this feature.  

[John__Carter]

To add to David's good points, ideally developers should not have access to the Prod environment, be able to 'mark their own homework' or implement their own work. However, this doesn't fit well when having to step through (or even develop) against Live applications - in this situation the Live credential could be accessible to the developer and it's a topic of debate here at BP. One option is to (temporarily) avoid using a credential and have an SME available to manually enter the password at the appropriate point. Not very practical I grant you, but if it was imperative that no developer could see a password, then this would be a way to do it. The 'cast to text' thing has always been there, and that it still is isn't an oversight. Even if there was a way to prevent this casting, you'd still only need to do 'send keys' into Notepad to see the password - you can't transmit encrypted characters and have the target app decrypt them. So as initially shocking as it may be to see the password revealed in this way, at some point between BP and the target app the characters have to revealed. This all being said, please feel free to voice your concerns as enhancement requests: https://portal.blueprism.com/community/enhancement-request For now, the best option is to secure the access to credentials by securing the environment and the operational model.

[AndreyKudinov]

Even browsers now mostly allow to look at the password entered, by pressing that eye button and there are loads of other ways to intercept it if you have prod access. Writing password to notebook/any text field is most obvious way to expose password even if casting is disabled somehow.