ipmi password storage

[Milton Miller II]

On Apr 13, 2020 around 6:01PM in some time zone, Vernon Mauery wrote:
>
>Internally, an issue was raised that basically says that the
>mechanism 
>by which we are storing the IPMI passwords on the BMC is
>insufficiently 
>obfuscated. I have come up with a patch set that resolves this at the
>
>expense of no downgrading the BMC without the side-effect of losing
>all 
>IPMI passwords. I would like to know what the community thinks about 
>usability vs. security in this scenario.

...

>The migration from the old mechanism to the new could be done simply>by 
>using the new key on the next write to the /etc/ipmi_pass file. After
>a 
>firmware update to this new code, a password change would trigger a 
>decrypt of the /etc/ipmi_pass file, a modification of the plain text,
>
>and a re-encryption of the data. If it reads the 'legacy' key in and 
>writes out the data using the new key mechanism and deletes the
>legacy 
>key, it would use the new key mechanism from that point onward.
>However, 
>this would cause any downgrades to prior versions to fail to decrypt
>the 
>/etc/ipmi_pass file, thereby losing all the ipmi passwords. This is
>not 
>ideal, but could possibly be mitigating by truncating the new
>machine-id 
>derivative password to 8 bytes and storing it in the /etc/key_file 
>instead of just deleting it. This might improve security only
>slightly 
>at for the price of a better user experience.
>

I'll point out the code to handle the new password could be added 
before the cdoe to use the new method, allowing test and revert 
until the users are upgraded to the new method.  It does require 
both methods to be supported.

I didn't follow why currently all openbmc systems end up with
the same encryption^Wobsfucation for what that is worth.

>I know that some companies using OpenBMC have products with users out>in 
>the field, so it is not great to make changes like this. Also, it is
>not 
>great to have low-grade security. So here I am, writing to ask for 
>opinions and options.
>
>--Vernon

Milton