ipmi password storage

[Patrick Williams]

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.

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

Agreed, but it isn't any less backwards compatible than the obfuscation
proposal.  This could certainly be staged in with a compile flag that
keeps the old file around.  If a vendor is concerned about backwards
compatiblity they could enable that flag for a period of time until
their customers upgrade through the new support version.  (Disabled by
default in meta-phosphor).

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

-- 
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/20200424/77bd170e/attachment.sig>