ipmi password storage

[Patrick Williams]

Vernon,

Thanks for the info.  It's taken a few days before I could find a time
slot to think about this in detail.

On Tue, Apr 14, 2020 at 09:46:10AM -0700, Vernon Mauery wrote:
> On 14-Apr-2020 10:50 AM, Patrick Williams wrote:
> >On Mon, Apr 13, 2020 at 04:00:15PM -0700, Vernon Mauery wrote:
> Specifically, the RAKP3 message (User->BMC) contains an HMAC of the 
> various parts of the exchanged session (User random number, session ID, Role, 
> Username) using the password as the key for the HMAC. The BMC needs to 
> compute this same HMAC to compare (this is the main authentication 
> challenge).
> 
> Then, the session key is generated using an HMAC of similar 
> data (BMC random number, user random number, role, username) using 
> either the user password or the channel password. Almost nobody uses the 
> channel password, which is good because it allows for simple privilege 
> escalation and session hijacking.

If I understand this right, the algorithm uses this to create a symetric
key for the session:
    HMAC(password, hash(pseudo_random_session_data))

The client gives some data to seed the session-data and the server gives
some data to seed the session-data, so that part is unique per
connection.  The part that is constant, and that they both have, is the
key to the HMAC.  Do I have that right?

The HMAC algorithm, at least for SHA-1/2, is a two-phase hash call, but
the key is always used at the front of the first hash phase.  The SHA
hash algorithms allow you to do a partial hash, extract the hash state,
and then resume the hash (See SHA1_Init / SHA1_Update functions in
openssl/sha1.h as example).  Rather than calling the OpenSSL HMAC
directly, can't we rewrite it such that it uses the partial hash on the
key as the starting point rather than the raw password?

This approach would allow us to save a SHA-1 + SHA-2 hash'd version of
the password rather than the raw (or even obfuscated) password.  It
isn't as secure as the normal crypt methods because we cannot salt them,
but we could certainly obfuscate the hash-state in a similar method to
what you already proposed.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200422/3aef968f/attachment-0001.sig>