From what i see in Current Type Into Secured Text , and get credentials activities , even if we are able to retrieve Password securely from either orchestrator or Windows Vault , Type Into Secure text basically can be used anywhere to type in the password.
For Eg , i can use it to type the password out on a Notepad. without any restriction on it. Or else i would be able to use it in Writeline / log it.
What if we are able to merge the selector with the password as well?
Eg - the way we store passwords would have 3 values .
Username
Password
Selector.
Once we retrieve the secured credential , we can keep it as a encrypted value of all three , and maybe use a custom activity , “Type into Secure Credentials” , which internally would be a combination of 2 Type Into Activities , with the selectors provided dynamically.
It might look like this.,
Get Secure Credentials
in – TARGET
OUT - COMBO Value of username+password+selector.
this out value could be input for
“Type into Secured Credentials”
Which would inturn be - Type into - Username
IN - username
IN - Selector
I heard this idea somewhere before, can’t remember where.
+1, with a precaution that a credential should also be possible to be stored without a selector (as a concious choice - some credentials are used in different places, as well as unfortunately some of them need to be converted to plain strings for requests).
I agree with you , we might want to retain capability to retrive password without selectors as well. The thought came in during a requirement gathering dicsussion where one of the application owners , had some compliance requirements to ensure the password is never visible in cleartext by hook or by crook. as the application contains sensitive information.
I think there might have already been requirements like these … The only way i could get them to agree was to bake in the selector with credentials which would ensure the password cannot be "Typed into " anywhere else apart from the application screen…
Is there any intention from UiPath to implement such functionality or something to address the same concerns ?
There is no way that anyone can effectively say credentials are secure in orchestrator when anyone with access to a robot connected to orchestrator can use “get credential” to write it in notepad (of course, they need to know the asset name but there are multiple ways to get it, including just reading from the config.xlsx file according to REFramework…)
There is an easier way than writing it to Notepad using some dot net syntax. But ya there are potential risks, but then again what’s the difference from going out of your way to get a password than just simply asking someone for the password? It’s still up to the associates to abide by the rules like not writing passwords down or saving them on your computer. Also, these things are being stored in logs and Audit so it can be tracked technically.
I think the main reason for the security rules with passwords are to protect the associates from sharing it unintentionally to someone that can do damage. If you are developing robots then you are not the problem; the problem is when the password gets outputted to places that everyone can see. And if you ARE the problem, then you should be moved to another position. So those are my thoughts on that
You don’t even need to get the password, cause you can just write the robot to log in anyway. See what I mean?
But yeah, we’ve discussed this a lot. We just try to follow good practice like not hardcoding passwords and keeping it private in logs, et cetera.
I would be rather ok with this, as long as the only way someone can log in is via a robot connected to UiPath which in turn we are sure to have logs of. The problem is one someone “knows” the password they may share it or use it outside of robot ecosystem.
Is there an audit or log of each time a robot accesses a credential asset ? This would also be interesting
Don’t take my comments as offensive, we are all trying to improve this amazing tool
True, but if someone knows the password they are not following the rules and best practices. Also, passwords typically expire. To be honest, the workaround (specifically the dot net expression) has saved me a few times to figure out if the password was correct. But, I understand if you want to remove all possibility that someone is going to purposely go and retrieve a password that they shouldn’t (thus breaking the rules like I have said). Just need to be careful though, because removing all freedoms can be very annoying - see Microsoft. And, yes, I agree with you that there are security concerns too.
The execution logs, that is made each time you run something from both Studio and Orchestrator, will show what variables were retrieved and activities that were performed. I’m assuming there will be enough information there. Also, if it’s on a server with an anonymous user id, technically IT can find out what IPs or computer names that accessed the server. I don’t know if the logging is that great but there is probably enough of it.
No worries. I’m a freedom fighter, which sometimes gets construed as offensive too.
Anil_G
ashokkarale
Ajay_Mishra
Gautham_Pattabiraman
BHUSHAN_NAGAONKAR1
vrdabberu
ABHIMANYU_THITE1
lrtetala
samantha_shah
shyamala_shyamu