ipmi password storage

[Alexander Tereschenko]

On 24-Apr-20 17:15, Patrick Williams wrote:
> On Wed, Apr 22, 2020 at 03:19:43PM -0700, Vernon Mauery wrote:
>> 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.
> I don't think that the interfaces we'd be needing to use here will ever
> be deprecated.  The "hash-resume" functions are needed in order to hash
> very large files that cannot be fit in memory.  They're just too useful
> to deprecate.
>
> You are correct that we would be effectively implementing HMAC ourselves
> using the SHA hash functions though.  It _seems_ straight-forward enough
> though on the surface.

Yes, that should be doable and HMAC is generally not that prone to 
implementation problems, so this is reasonable to assume it could be 
done safely using just the plain hash primitives. The major problem with 
this one, from my standpoint, is that the unsalted hashes are these days 
a too easy target for attackers, as hash tables can be (and actually 
are, you can download those I believe) precomputed on password 
dictionaries and without salt it's a BORE-type risk (break once, run 
everywhere) - the hash will be the same on all BMCs if the password is 
the same, so compromising one means compromising others.

>> 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.
> Agree on keeping anything like MD5/MD2 out of it.
>
> I'm not a cryptographic expert, but I'm not sure it "greatly reduces"
> the effectiveness.  The addition of the SHA-2 state probably doesn't
> help you reverse or collide the SHA-1 much at all, so this is only
> slightly weaker than SHA-1 itself.
>
> My reading on the SHA-1 algorithm would lead me to believe that SHA-1 state
> is the same as SHA-1(password) itself.  Meaning, by doing this partial
> hash we're not weaking the algorithm at all.

For SHA-1 and SHA2-256/512 the hashing output *is* the hash internal 
state at the end of calculation, so there's no additional compromise 
here from the crypto standpoint. Essentially, this proposal is a hash 
length extension attack, but used for good, not evil :) The problem here 
is with hashes being unsalted, but I agree this is still better than 
encrypting with a static key thay lies nearby. FWIW, that DTLS solution 
looks a bit better to me as it allows us to ditch that password thing 
completely, but if that one is not possible, this one could be the next 
best.

BTW, Vernon, could you please elaborate why it's 4 values that we need 
to store here? One is SHA1, another one is SHA2-256, but what are the 
other two?

regards,
Alexander