All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Milton Miller II" <miltonm@us.ibm.com>
To: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: OpenBMC Development <openbmc@lists.ozlabs.org>
Subject: Re:  ipmi password storage
Date: Tue, 14 Apr 2020 18:04:36 +0000	[thread overview]
Message-ID: <OFED1A87B9.D16D66BD-ON0025854A.004EDFC4-0025854A.00634C8E@notes.na.collabserv.com> (raw)
In-Reply-To: <20200413230015.GB9295@mauery.jf.intel.com>

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

  parent reply	other threads:[~2020-04-14 18:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 23:00 ipmi password storage Vernon Mauery
2020-04-14 15:50 ` Patrick Williams
2020-04-14 16:46   ` Vernon Mauery
2020-04-14 22:03     ` Joseph Reynolds
2020-04-14 22:42       ` Vernon Mauery
2020-04-16  6:04         ` Joel Stanley
2020-04-20 14:29           ` Vernon Mauery
2020-04-22 11:38     ` Patrick Williams
2020-04-22 22:19       ` Vernon Mauery
2020-04-24 15:15         ` Patrick Williams
2020-04-29 16:02           ` Alexander Tereschenko
2020-04-14 16:27 ` Alexander Tereschenko
2020-04-14 19:11   ` Vernon Mauery
2020-04-14 22:18     ` Joseph Reynolds
2020-04-14 22:44       ` Vernon Mauery
2020-04-14 22:48         ` Joseph Reynolds
2020-04-15 20:32           ` Joseph Reynolds
2020-04-14 18:04 ` Milton Miller II [this message]
2020-04-14 19:14   ` Vernon Mauery
2020-04-14 22:30     ` Joseph Reynolds
2020-04-14 22:47       ` Vernon Mauery

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OFED1A87B9.D16D66BD-ON0025854A.004EDFC4-0025854A.00634C8E@notes.na.collabserv.com \
    --to=miltonm@us.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=vernon.mauery@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.