UiPathTeam.Encryption.Activities - key hardcoded?


#1

Just saw the package by @Priya_Dubey (https://gallery.uipath.com/packages/UiPathTeam.Encryption.Activities#) and I have to ask:
How is it secure if there’s no Key argument? Is it hardcoded?
For a symmetric algorithm (like Rijndael), or actually any two-way, to work, it has to have a secret, otherwise anyone having access to the implementation (so anyone who can download the package) can decrypt anything.

If it really is hardcoded, then it’s just obfuscation (which is better than nothing, but not really “encryption” anymore).
If it’s not, then how it is supplied?


#2

This raises a wider point - are gallery additions going to be validated in any way or are they to be used at the consumer’s own risk?


#3

Some questions were already answered and yes, basically only UiPath. (not UiPathTeam.) packages are fully vetted. For the rest it’s just verification of the owner, not the code.
From what I’ve heard there are some investigations on how to make the separation clearer (f.e. Documentation takes you straight to Activities guide, which will not cover most of the packages since they’re from “outside”).

I’d hope for a process to emerge for UiPathTeam activities as well, as even if they’re not from UiPath dev/activities team, they’re still from UiPath (company).

But that is a wider topic I think :slight_smile:


#4

They will be validated in the sense that we’ll put in place a process to make them open source… which means that the community will be able to asses the risk much easier.


#5

@andrzej.kniola , Thanks for the feedback.
You are right, for now my initial version is focused only on realizing the encrypt/decrypt functionality using activity package, hence the key is harcoded inside the package for the ease of use.
Also, the key(cipher) is generated using “embedded Passphrase” | “Randomized Salt” | “Randomized IV”.

Will soon, try to release an improved version…any more inputs are welcome.
Thanks Again.


#6

You can always write them as standard classes, possibly Internal, and add activity as a Proxy later.
It also makes code easier to test and reuse, as the implementation that does actual work is decoupled from activity implementation (one-way dependency only).
Added bonus is if you leave the class public it can be used inline instead of separate activity as well, which is useful in some scenarios (less temp variables, less visual clutter in workflow).


#7

Thanks, I’ve now seen the gallery thanks to your intro today, and I really like the tick boxes for verification - that’s exactly what I had in my head :slight_smile: