[pbs-devel] [PATCH proxmox 07/12] sys: crypt: add helper to allow upgrading hashes
Stefan Sterz
s.sterz at proxmox.com
Fri Feb 23 10:26:25 CET 2024
On Mon Feb 19, 2024 at 7:50 PM CET, Max Carrara wrote:
> On 2/15/24 16:19, Stefan Sterz wrote:
> > `upgrade_hash` function allows us to transparently upgrade a password
> > hash to a newer hash function. thus, we can get rid of insecure hashes
> > even without the user needing to log in or reset their password.
> >
> > it works by retaining only the settings of the previous hash and not the
> > hash itself. the new hash is a salted hash of the previous hash,
> > including the settings.
> >
> > the `verify_crypt_pw` function is also adapted to deal with the new
> > string format. it verifies hashes whether they've been upgraded or not.
> >
> > Signed-off-by: Stefan Sterz <s.sterz at proxmox.com>
> > ---
> > this is a far from ideal method of upgrading hashes. as the input to the
> > new hash function has several well-known parts, it may break the
> > security assumptions of a newer password hashing function. it could be
> > possible that finding collisions is made easier compared with re-hashing
> > the original password. hence, only do this as a stop-gap meassure.
> >
> > also, my choice of `HASH_SEPARATOR` is possibly not ideal. i welcome
> > some bike-shedding there if we want to consider this approach at all.
>
> I know you've meticulously tested this, you gave me a demonstration of this
> as well, but it still makes me feel uneasy nevertheless - IMHO it is long
> overdue that we upgrade our hashes, but there must be a cleaner way to do
> this that doesn't involve keeping those amalgams of crypt hashes around.
>
> There are quite a few comments inline, but I do want to mention that I
> realize that this took you a lot of work, so I highly commend your efforts
> on this.
>
just wanted to say, after off-list discussions, i'll retract the
hash-upgrading mechanism. it would only be useful if there is a
pre-image attack on sha2 while exposing our users to potential
known-prefix attacks. if a sha2 pre-image attack becomes publicly known
we can reconsider this.
thanks for the suggestions, though! i do think that they would make all
of this a bit cleaner!
(i'll trim the rest of this message, though, as imo it's not relevant to
further discussions until the attack mentioned above does become known)
-- >8 snip 8< --
More information about the pbs-devel
mailing list