If you use MID servers in your organization, then you know that there's a configuration file (config.xml) for each instance of a MID server. Amongst the configuration entries in that file is the user name and password that the MID server uses to log into your instance with. That password is the topic of today's post. It's "in the clear", meaning that someone who had access to the file could read it.
For many organizations, this isn't an issue, as all those users with the rights to read the config.xml file have access to that password anyway. However, for some organizations the MID server hosts aren't quite so locked down, and that password being in the clear is a security issue. Well, now things don't have to be quite so clear...
How so? Well, now (starting with the Winter 2011 release) you've got the option to have that password stored in encrypted form in the config.xml file. Actually, you can now store any field you want to in encrypted form — though doing so really only makes sense for sensitive fields like passwords. Storing other fields in encrypted form means that you will no longer be able to manage these values from your instance — for most folks, an undesirable result. So we recommend that you use this feature only on password fields.
Here's how you do it. First, here's what the instance credentials section of your config.xml file might look like now:
<parameter/>
<parameter/>
If I edit that file to look like this (adding the encrypt attribute to the password tag):
<parameter/>
<parameter/>
And then restart the MID server, the config.xml file will be revised to this:
<parameter/>
<parameter/>
Once the password has been encrypted, setting the encrypt attribute to "false" (or deleting it altogether) will not decrypt the password. Changing the encrypted value to a new password and restarting the MID server will cause the new password to get encrypted.
The crypto-geeks amongst my readers will be asking "What's the encryption key and algorithm?" The algorithm is AES with a 128 bit key; the key is fixed, generated algorithmically when the MID server starts. All of that is a fancy way of saying that this isn't NSA-grade cryptography being used here, but it is very effective against sub-NSA level snooping on your config.xml file. Our model was the credentials encryption used in Cisco IOS files (for the same reasons we've used it here), which works very similarly...
2 Comments
