ipmi password storage

[Vernon Mauery]

On 22-Apr-2020 06:38 AM, Patrick Williams wrote:
>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?

Yes.

>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?

I had to code up a quick test to make sure, but yes, it is possible to 
do this.

>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.

Pros and cons of this new solution:
Pros:
1) Obfuscates passwords more than currently. A hash is even harder to 
deal with than an encrypted file that has the key sitting right next to 
it.
2) Item one is a very strong plus

Cons:
1) Would require us to write or hack up an HMAC that would work for us. 
This is not ideal; writing crypto stuff is generally best left to the 
experts. OpenSSL is trying harder and harder to hide its internal 
workings from its API, so extracting the hash state is hard. libTomCrypt 
allows you to do this easier, but still does not have an HMAC function 
that takes two partial hash states as inputs.
2) Is not backwards compatible with any of our current password storage 
mechanisms. This is workable, but would likely take some time to stage 
things so that they would work better without breaking everything.
3) We would need to store two hashes of each password for both SHA1 and 
SHA256, for a total of 4 states per password. This greatly reduces the 
effectiveness of the solution in the first place. Not that we are 
planning on adding MD5- or MD2-based cipher suites, but those would 
break the value of this completely.

So pro-1 is good. but con-2 and con-3 are bad. Con-2 we can deal with, 
but con-3 brings down the value of pro-1.

--Vernon