Internal Object - Credentials

[Akhlesh_KumarJi]

HI, I am exploring Internal Business Object "Credentials". There is one action "Generate and Set". New Password is generated using this action stage. Since it is stored in [Password] data item, so not readable. I used Internal Business Object Encryption action Decrypt Password, input field - Encrypted Value is not accepting [Password] data item as text. I am wondering what is the use of this newly generated password. Thanks.

[BenKirimlidis]

Assuming its a format issue you can try casting the new password as text and then inputting it

[david.l.morris]

Quick answer: If you just want to see what the password is in plain text, do as Ben suggested and cast to a text data item. Be aware that a practice like this should generally only be done in a Development environment and should never be in any solution that is to go to Production unless there is a specific reason for it. I can't think of any reason why that would be a good idea though. I'll explain more below because this is something I looked into a while back to understand it better. I can see where this could be confusing. What's happening here is that you're using two features that aren't meant to be used together. The Internal Business Object 'Credentials' usually accompanies the use of Credential Manager (System tab). The actions 'Generate and Set' as well as 'Generate Password' will generate a random password and give you an output that is of the Data Type 'Password'. Now, I don't really understand how the data is stored in memory while there is data in that password data item. But I can show you the difference between this and encryption. I put the word 'test' into the initial value of a data item that is set to Data Type 'Password'. Then I selected the data item in Blue Prism, hit CTRL+C to copy it, and then I pasted it into Notepad. The value displayed where the initial password was came out to this: 53,16,7,68 I did the same thing again but this time I put 'testtest' into the initial value. Here's what it comes out to: 53,16,7,68,25,81,7,17 So, it's encrypted in some fashion and the number of values directly relates to the number of characters in the password, but I have no idea what this kind of encryption is called. It is not, however, related to any Encryption Scheme saved in Blue Prism. That wouldn't make sense anyway, since usually the Encryption key is stored on the app server and I don't think casting from a password data item to a text data item needs to contact the app server for this. Anyway, so, now if I put the word 'test' into the input of 'Encrypt Password' in the 'Encryption' Internal Business Object, here's what I comes out to for me in one of my test environments: 8e2adWZ/Gs5zz1iDhc1zug==:2N4SnJnVDkuB55Lh90979A== This is a text data item because it is already encrypted. It would be pointless for it also to be a password data type, I guess. So, if you generate a password using the Credentials object, you cannot get that password using Decrypt Password. If you could somehow retrieve an encrypted password from the database, then I imagine using Decrypt Password with the right Encryption Scheme would decrypt the password. But that sounds like a compliance issue. =) I've typed a lot so I'll just stop now. You probably weren't asking for this much info anyway. If you have more questions, I have more text I can type. 😃

[AndreyKudinov]

@David, this is bitwise xor with key "Aut0m4te". Ascii code for 'A' is 65, so 65 xor 53 is 116, which is ascii code for 't' and so on... it is just static key. You can not have a password encrypted and useable to blueprism at the same time. It is impossible to protect password from a local user if process is supposed to be runnable on that same machine. Which leads us to another point - you should never hardcode passwords in process or VBO, only store them in credentials and retrieve them from there while process is running. Then if someone should not have access to password - you deny them access to this credential.

[AndreyKudinov]

p.s. Encryption Internal Business Object should use a strong encryption and safe to use.

[david.l.morris]

Agreed with aikudino on the password practices. On the note of the ASCII code thing. It did not give me the same code for each letter even though I typed the same word twice in a row. It occurred to me it might have been static codes, but I didn't understand why 'testtest' did not give me 4 numbers twice like 1,2,3,4,1,2,3,4. Though, now that I look again, the 3rd digit (7) was the same in both groups. Maybe I just did something weird. Anyway, good to know! Thx!

[AndreyKudinov]

It should not give you the same code for same letter, because each letter is xored with different letter of a key (repeating) - first 't' xor 'A', third 't' xor 'm'. Since "Aut0m4te" is 8 letters and so is "testtest", if you try "testtesttesttest", it will actually repeat starting from 9th letter.

[david.l.morris]

I gotcha now. I asked my good friend, Google. So it is a kind of encryption then with a static key that is hardcoded to any installation of Blue Prism. Is that a normal practice?

[AndreyKudinov]

As I noted before, the only problem you can get with it is if you export vbo with hardcoded password and publish it somewhere, but that is a violation of normal security practices, not just in blueprism. If that key would be dynamic, you wouldnt be able to reimport it to another installation in "working" state, however some export warning ("You have a hardcoded password") could be nice.