Is using system properties to store passwords not secure?

[phillipkeigley]

While doing some compliance work, I noticed that i could log in scripts background the actual value of system properties of type password or password type2.  I was not able to log data source[sys_data_source]] passwords or auth profile[sys_auth_profile_basic] passwords.  

If you have many applications that require passwords being stored somewhere; what is best practice?  Is it against best practice to store passwords in system properties?  

Thanks for any help, code for scripts background included below:

gr = new GlideRecord('sys_properties');
var grOR = gr.addQuery('type', 'password');
grOR.addOrCondition('type', 'password2');
gr.query();
while (gr.next()) {
	gs.info('property type: ' + gr.type + '  ' + gs.getProperty(gr.name.toString())); //type is password or password2, gs.info prints the actual password in scripts background
}

r = new GlideRecord('sys_data_source');
gr.addNotNullQuery('jdbc_password');
r.query();
while (r.next()) {
	gs.info(r.jdbc_password); //password field here is "internal type Password (2 way encrypted)  -- These appear encrypted when gs.info'd.
}

z = new GlideRecord('sys_auth_profile_basic');
z.query();
while (z.next()) {
	gs.info(z.name.toString() + z.password); //password field here is "internal type Password (2 way encrypted)  -- These appear encrypted.
}

[sachin_namjoshi]

Use below code to encrypt, decrypt passwords

var Encrypter = new GlideEncrypter();  


var encrypted = current.u_password; // current.<<your field name>>  


var decrypted = Encrypter.decrypt(encrypted);  


gs.addInfoMessage("encrypted..   " + encrypted);  


gs.addInfoMessage("decrypted..   " + decrypted);

Regards,

Sachin

[phillipkeigley]

So question; with the Script below, I can print in plain text what all the data sources passwords are, auth sources passwords are, and password properties are to the syslog.

That leaves me with this question; what is the best practice then?

1. Encrypt the passwords you put in sys_properties via scripts background with code above.
2. there must be one unique data source for both dev, test, stage, and then one unique to prod.
3. Limit access to test, stage, and prod to only system administrators.  (no devs with admin in test,stage,prod only in dev)
4. For auth profiles, not really sure.  I guess make sure the auth profiles do not have ServiceNow sys_admin role, and if they do, have different ones for dev, test, stage, and then prod?

Anyone have any others?

var Encrypter = new GlideEncrypter(); 

gr = new GlideRecord('sys_properties');
var grOR = gr.addQuery('type', 'password');
grOR.addOrCondition('type', 'password2');
gr.query();
while (gr.next()) {
	gs.info('property type: ' + gr.type + '  ' + gs.getProperty(gr.name.toString())); //type is password or password2, gs.info prints the actual password in scripts background
}

r = new GlideRecord('sys_data_source');
gr.addNotNullQuery('jdbc_password');
r.query();
while (r.next()) {
	gs.info( Encrypter.decrypt(r.jdbc_password)); //password field here is "internal type Password (2 way encrypted)  -- These appear encrypted when gs.info'd.
}

z = new GlideRecord('sys_auth_profile_basic');
z.query();
while (z.next()) {
	gs.info(z.name.toString() +  Encrypter.decrypt(z.password)); //password field here is "internal type Password (2 way encrypted)  -- These appear encrypted.
}

[Community Alums]

On the platform, it's pretty limited. You can obfuscate to a certain extent, by encrypting the data beforehand, or base 64 encoding and the like, which might deter people who aren't curious, but the decryption in the scripts will give you away, if people look for it.

If you have to store passwords in ServiceNow, don't store any passwords that provide access to production systems in your non-prod instances, and limit admin access to Production.