IBM Integration Community Come for answers. Stay for best practices. All we’re missing is you. Join / Log in Ask a question
Hi Peter,> Is there anyway to make the MQ Client work if the stash file is located in some other location?Unfortunately not, MQ is hardcoded to look for a stash file in the same location as the keystore and with the same name (just a .sth extension).> Thinking out loud.....And/or a way to make that keystore/stash combo only viable if executing on the specific O/S instance that was used during the CSR when the key was created?sorry, but again also not possible. The stash file provided by GSKit doesn't link with the OS/folder so as long as it's a stash file containing the obsfucated password then it can be used to open the keystore anywhere (as long as you're using GSKit's/MQ's tools).> Other than relying on folder permissions, what else can be done?Are you aware of the alternative to Stash files that was added in MQ 9.3? We added the ability to provide the keystore password either programmatically or encrypted using the IBM MQ password protection system. If you modified your application to provide it programmatically then you could do a lot of the things above you want to do, like storing it remotely or even requesting it from a store such as hashicorp vault. If you can't provide it programmatically then you could look into storing the password with the Password Protection system. You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key.This page talks about the password protection system: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=securing-protecting-passwords-in-mq-component-configuration-filesThis page talks about supplying a keystore password: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=wsalw-supplying-key-repository-password-mq-mqi-client-aix-linux-windowsLet me know if this helps!
Hi Rob,Thanks for the info, I was not yet aware of this. So yes its a step in the right direction to allow this to work without a stash file. It looks like the stash file can be replaced with an encrypted password along with the key used to encrypt that password. So we've traded a stash file that must not be compromised to the key used to encrypt/decrypt the password that must not be compromised.
Rob wrote>> "You would still need to store the password (and the initial key that is used to encrypt the password) but these can be split apart away from the keystore and even if an attacker obtains the encrypted password and initial key they shouldn't be able to open your keystore without knowing how to go from initial key -> encryption key."So the fact that the encrypt/decrypt key can live somewhere else is the improvement over the stash file that must be co located with the keystore. OK, that is a little better, a little more complicated for the bad actor. I did not understand this part: "....without knowing how to go from initial key -> encryption key."Isn't the initial key the same as the encryption key the same as the decryption key? I guess I don't understand the details about this key yet. What kind of key? This key file(?) must be available to runmqicred at set up time and the same file must be available to your MQ app at runtime to allow access your certificate keystore?I don't find documentation on the runmqicred command in the 9.3 Knowledge Center. I see multiple references to "the IBM MQ Password Protection System". Is there an article or presentation that describes this system?
You mentioned you were going to write a blogpost on this topic. Is there any more info to share?
I'm playing around with this. Running the same password into runmqicred on the same MQ Client install gives a different encrypted result each time. This was surprising to me - I assumed same input would produce the same output each time. Using any one of those multiple encrypted outputs (again, all for the same exact input password) worked. Altering even one character in any of them caused it to fail, as expected. I assume the MQ Client install is keeping some internal list of results for every invocation of runmqicred? Where? I assume/hope securely. In a Redistributable MQ Client install, what happens the next "upgrade" where we delete the entire folder structure of the old version and drop the new version - I'm guessing we have to go thru the runmqicred exercise again for each keystore referenced by that install? Does redoing the runmqicred need to occur anytime any type of MQ upgrade occurs, even the in place upgrades?
"Running the same password into runmqicred on the same MQ Client install gives a different encrypted result each time."
It probably appends/prepends a random IV to the password before encrypting it. On decryption, the IV is ignored.
It probably also uses a hash/MAC in the encrypted data, to check that a decryption is correct.
Sorry the blog post on this topic has been a long standing item on my TODO list that i haven't been able to find time to action.
As Glenn says below, the reason you get a different output each time you encrypt the same plaintext password is because each time we use a random IV when encrypting the plaintext.
I can't go into too much detail as I'm still awaiting approval on how much we can share in a public space but i will say that everything that MQ needs to be able to decrypt a password later is included with the MQ installation and encryption string.
If you take that string and use it in another installation then it should be compatible so long as you aren't using it with a different "component" and you have ensured you're passing in the same initial key. By component i mean the passwords encrypted with runmqicred cannot be used with AMS, for those you should use runamscred.
In the future this could change and a later version of MQ may not be able to use an older encrypted password. In those cases we would let everyone know and the procedure would be to re-encrypt your passwords. But for now, the encrypted passwords should be useable between platforms, versions and installations.