What controls exist to prevent ServiceNow decrypting passwords stored in the credentials table?

[Adz1]

It's a question that comes up with every Discovery implementation I've ever done, but I've never found a satisfactory answer. 

Passwords stored in the credentials table are encrypted, yes.
A support agent once informed me that every instance has its own unique encryption key, ergo credentials must be entered manually in each instance rather than being XML'd across between dev, test, and prod.
They're decrypted and re-encrypted with the MID server's key whenever the MID needs it. 

But when the data is at rest in the database, the instance's encryption key and the data are both under ServiceNow's control and not in the hands of the customer. 

Therefore, there is a theoretical risk that a rogue SN employee could decrypt the passwords stored in the credentials table.

Obviously, that is highly unlikely to ever happen and external credential vaults exist for those who prefer to keep the keys to the kingdom within the walls of their castles, but Information Security teams still want reassurance that there are some controls around it to reduce the threat surface area. 

So, the next time a customer asks, "could ServiceNow in theory decrypt our passwords stored in the credentials table?", what can I tell them to offer reassurance that there are mitigations to ensure that doesn't happen? 

[Logan Poynter]

Hello adz,

The encryption key is built into ServiceNow and not stored in the instance databases, scripts, etc. and is not visible through the user interface at any time. So there is no way to get access to this key from an instance even with admin role.

For future cases, I'd review this article with your customers as it has thorough documentation on encryption/decryption with discovery. 

Please mark my answer as correct/helpful if it has helped you.

Thanks,
Logan

[shloke04]

Hi Adz,

That is correct the password stored in Credential table can be decrypted by anyone who has the knowledge of scripting and can use background script to decrypt it as the OOB Password field on the credential table is of type = Password 2 as shown below:

So as far as I am aware of ServiceNow support below two type of Password as per details mentioned below:

Password (1 Way Encrypted)	Text field that stores passwords with one-way encryption. One-way encryption stores the password as a secure hash value that cannot be decrypted.
Password (2 Way Encrypted)	Text field that stores passwords with two-way encryption. Two-way encryption stores the password as a secure encrypted value that can be decrypted programmatically within the instance.

 For example, below script can decrypt your Credential password and is not secured.

var gr = new GlideRecord('basic_auth_credentials');
gr.addQuery('sys_id','ca47b8abdbedb810e37edd18f496196b');
gr.query();
if(gr.next()){

var Encrypter = new GlideEncrypter();  
var encrypted = gr.password; // current.<<your field name>>   
var decrypted = Encrypter.decrypt(encrypted);  
gs.info("decrypted..   " + decrypted);
}

Solution Which I have proposed to my existing and previous customer which I believe is more secured and easy to implement as well:

1) Use External Authentication, like CyberArk tool is a good application which can be used in these type of scenario and credentials all other password can be stored in CyberArk and not storing the credentials locally at all.

This was it makes ServiceNow more secured and only say a handful of people say 1 or 2 will have access to CyberArk account and not all and when ever ServiceNow need it , it can fetch it from CyberArk and use it.

Please go through below doc and implement or suggest to your future clients which should work:

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/credentials/concept/c_CyberArkCredStorageIntegrate.html

This links explains step by step procedure on how to implement this and from ServiceNow end it is only configuration with no coding required to set up this.

I have done this in my current project as well, so if you are stuck do let me know can assist further.

Hope this helps. Please mark the answer as correct/helpful based on impact.

Regards,
Shloke

[Daniel Oderbolz]

Note that 1-way "encryption" is called hashing by everybody else (don't know why ServiceNow chose this naming). It cannot be "decrypted" (hence 1-way) and therefore cannot be used to encrypt a password.

[shopsnow]

Hi,
 
I'm attempting to reproduce this decryption in a Washington DC PDI. It works to retrieve unencrypted fields (e.g., user_name), however calling decrypt as an admin returns the error:
 
Access Denied to cryptographic module 'global.com_snc_core_automation_connection_credential_glideencrypter' For guidance on this issue, please have your Security Admin refer to KB: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1112530 : no thrown error Access denied to crypto module
 
Is this still feasible or was the issue resolved in more recent releases?
 
Thanks,
Joe