Roast on BP 7.3.1 (and in general I guess)

[jacktian_opal]

We are currently using BP 6.10 and are moving to 7.3.1. I am in charge of the preview and migration assessment, but I got frustrated for some of the changes in 7.3.1 - or any version in between. Especially how incompetent it is.

One of the first thing I noticed is the change in behavior of data item with type Password - you can no longer store a Password output into a data item of type text - presumably of security concerns.

On the paper, this looks like an improvement of security, however, it is but an inconvenience for the developer. It is only as secure as your weakest link, so when you can revel it by just assigning it again to a text, I would argue there is little to no improvement on security. However, to make the code work, code change is required for all the occurrences where a Password output is stored into a text.

Obliviously it is not the best practice to store a password output into text - and mostly you don't really need to. But there is one valid use case that is caused by BP's incompetence for having no way to specify the type of additional properties in a credential manager as everything is presumed to be of Password type. In certain cases, there are credential related properties that are not required to be secured (e.g. tenant id for an OAuth Credential, email address for an email related credential where the email address is not the username)

So I think it is understandable -

If BP is set to never allow converting from Password to Text - either via output storage, calculate stages or passing into pages/objects taking text input, with the additional property types implemented in the credential manager;

Or if BP is set to leave this discretion to the developer as it was in 6.10;

To be fair you can you export the package and change all your process addressing this in one go, but what I don't really understand is the incompetence of the decision for this implementation that does pretty much nothing but creating troubles for the developer.

There are other issues that I might post later but at this stage I am pretty frustrated.

[ManojKothapalli_G]

Hello @jacktian_opal - I think it will benefit organizations security terms according to access privileges given to users and groups in different environments.

While the change is intended to improve security by preventing the exposure of sensitive data, it does create additional burdens for developers. Your point about the security being only as strong as its weakest link is valid; simply restricting the type doesn't fully address the need for secure handling of credentials.

The need to update all instances where passwords were previously stored as text is indeed a significant overhead.

[jacktian_opal]

Thanks for the reply.

Yah, I also agree that the intention was good. But when I have to think how this implementation was made, from how this is discussed within BP's dev team, to how the PM approved the change, to how the testers/security team passed this, it does not give me as the BP's end user much confidence if at all, and that is where my frustration actually coming from.

Together with some other nonsense practice that BP has been doing, it is rather disappointed to see how once a good RPA tool is getting to where it is at right now and where it is going to.

Jack