Before I was able to store email passwords in the Windows Credential Store and pass them to the Email activities as variables.
How am I going to achieve this since now I can retrieve only secured string which works only in type.
As Genfour suggested we need to create an activity that returns a string from a SecureString.
Until then String plainStr = new System.Net.NetworkCredential(string.Empty, secureStr).Password
should work http://stackoverflow.com/a/38016279/1430597
My belief is that if you want to pass a genuinely secure string you should not be able to decrypt it. To make this work you will need to ensure/consider the following:
All activities accepting a password have the option for a string password or a secure string password (possibly just secure string)
You cannot use type secure text to type unless the object that you are typing into is secure e.g. a password box. However, don’t think this is possible so perhaps needs to just be covered by dev standards.
If you cover both of these then the issue of decrypting the secure string goes away I think.
I’m trying to use “Get Credential” but I only find the “Get Credential” activity of Orchestrator package, so I’m not able to retrieve the credential stored in the Windows Credentials of the local machine
@andraciorici, @Lavinia, @Horia
By exposing this method of retrieving secure password from Windows Credentials Vault we are ultimately compromising the security; as any developer can write this piece of code ant Production system and get the passwords from vault.
How can we avoid this security breach :
Do we need to import any special Packages/API in order to make this code working? And is there any way we can disable such APIs so code won’t work?
What can be other possible solutions to avoid such issues?
This is not true. The reason is that the unassisted robots runs under a Windows Credential that other developers can not access. Therefore they won’t be able to retrieve the passwords stored in production as they can not login to the robot machine under the robot account.
They will have access, of course, to dev/test credentials.
Hi @fmsimoes, it’s not a bug and was built that way in vb.net or C# I guess.
The point of the SecureString is so sensitive data is not stored in plain site. I don’t think it was meant as a way to keep programmers 100% from being able to extract that data, since there are times when you need to use it as a string (but it won’t be stored as a string). I know there is definitely security concerns around it. I think though that there is enough auditing happening that using that data in a damaging way would be caught, and what’s the difference in just simply creating a robot to do all that anyway? So, you still need to follow your security guidelines either way.